I'm kinda surprised I couldn't find an answer to t...

# javascript

[Toddobryan]

I'm kinda surprised I couldn't find an answer to this question from Googling, but maybe I didn't know the right incantation. I'm writing a library I'd like to use backend and on clients, and I'd like its treatment of regular expressions to be the same so that I don't have to worry that a regex will match on one side but not the other. Is there a way to do that, possibly by depending on a JVM Javascript engine or something?

[Casey Brooks]

Kotlin has a regex wrapper that works quite well https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.text/-regex/index.html. In general, the pattern syntax for JVM and JS are very similar, I think you’d be hard-pressed to find this much of an issue. Sticking to the provided regex classes will likely serve you better in the long-term as it is officially-supported

[Toddobryan]

The problem is, if it ever does turn out to be an issue, tracking down the problem would be close to impossible.

[Casey Brooks]

But if you want to run the exact same regex engine on both the client and server, it looks like JDK 8's Nashorn engine should support the native JS regex functionality https://stackoverflow.com/questions/32571402/matching-javascript-regex-using-nashorn

[Toddobryan]

Yeah. That's what I found. Was wondering if I was on the right track.

[Casey Brooks]

Yeah, I think Nashorn is the best JS engine you’ll find on the JVM, unless you’re running GraalVM. Though, personally, I would consider using Nashorn for regex a premature optimization. I would consider the Kotlin.regex to be correct and wait for an actual use-case that fails and does not have a sensible alternative.

Being a library, all internal uses of regex could be verified to be correct with your own unit tests, and anyone using the library just needs to be aware of this and unit test their regexes in the same way.

[Toddobryan]

I'm writing some validation and what I'm worried about is something matching a regex in the client, but then not on the server or vice versa. That would be incredibly confusing.

[Casey Brooks]

An alternative might to to do all validation on the server, maybe with websockets to make it really fast. I think any way you cut it, there’s the possibility of having it validate differently in the client vs the server. Nashorn is its own implementation, and it doesn’t support the latest ES6 standards, so any JS run in Nashorn is not guaranteed to run the same as in the browser

[Casey Brooks]

Just a note, I don’t think the Kotlin team would have made kotlin.regex simply a wrapper over the platform-native regex engines if they thought they were different enough to be problematic. If that were a major concern for the Kotlin team, I’d imagine they would have written their own pure-kotlin regex engine, or not done it at all. The fact that it exists shows that they have some level of confidence that it can be safely used in a multiplatform setting

[Ian White]

Nashorn was deprecated in JDK 11 and is now officially unsupported, so i wouldn’t build anything new on it, unless you’re certain you’re staying on JDK 8 for a very long time. You can use GraalVM without changing over the runtime. That said I agree, I don’t think you need a JS engine for this problem and I’d just use Kotlin’s regex.

[Casey Brooks]

Oh wow, I had no idea you could run GraalJS on a normal JDK, and is distributed just as a Maven dependency. Even works back to JDK8! https://github.com/graalvm/graaljs/blob/master/docs/user/RunOnJDK.md

[Toddobryan]

Notice though, that kotlin.regex points you to different grammars depending on which runtime you're targeting. In particular, I don't think the JS library supports POSIX character classes, so you could create a regex that works on the JVM, but then when you port over to JS it wouldn't work, and I'm not sure if you'd find out about that at compile-time or have to wait till runtime.

[Casey Brooks]

is it end-users that will be entering the regexes, or developers?

[Casey Brooks]

Also consider that if you do embed a JS engine to run regex, then the normal Java regex patterns might not be compatible with your library. Devs trying to use it just as a normal JVM library will run into these same issues, of regexes not necessarily working the way they expect. You’re going to have problems any way this is implemented, the only thing you can do is make it very clear in your documentation what’s going on and what regex features are supported, and be encourage unit-testing each regex pattern on all supported platforms which will catch these incompatibilities at build-time

[Toddobryan]

Yeah. It's users, so out of my control.