javascript engine: update J2V8 or migrate to graalvm or something else

[nedtwigg]

J2V8 is having trouble keeping up with the latest node/npm versions, and has given up (for now) on supporting them on desktop (now android-only) eclipsesource/J2V8#441. That's not a huge problem, we still run fine, but the latest version of prettier we can support is 1.19.0 - we'll need to migrate to something else in order to support newer versions.

One possibility is frontend-maven-plugin which has a non-maven-exclusive lib. J2V8 is unique in that it allows us to call node.js functions natively, anything else will be a big performance hit for our usecase.

[nedtwigg]

Another good bet is graalvm. We already have a few steps which require Java 11+, it would be okay to start requiring Java 11+ for our javascript-based plugins. We currently build and ship using Java 8. If someone makes a working PR that requires us to bump minimum to Java 11, please feel free to do so.

Once we have a working PR, we can evaluate whether we want to bump the minimum, or factor-out this portion to a separate module to keep Java 8 support.

[simschla]

Another idea I had (before going the J2V8 path) was to use actual native node.js to run a rest-service. That service could allow a REST-Interface to call prettier and tsfmt inside the node process from our spotless run inside the jvm. Kind of like the gradle daemon: Spawn a service with node, that can then be used to format the code for us by calling a local rest interface from the spotless build. That way I would not expect a massive performance hit, since the node-rest-service would be a long-running process, not one that we would need to start per file (which would kill the performance for sure).

[caoccao]

An alternative way is to use an embedded Node.js runtime Javet. It brings the genuine Node.js environment and supports JDK 8.

[nedtwigg]

Javet looks fantastic, J2V8 was very helpful, glad that somebody else picked up that idea with modern V8. Looks like it doesn't bundle npm though, so we'd be on our own to grab dependencies from npm. At this time, I don't see a way that Javet simplifies our overall situation, but feel free to open enhancement-request issues or to discuss further here :)

[caoccao]

Javet looks fantastic, J2V8 was very helpful, glad that somebody else picked up that idea with modern V8. Looks like it doesn't bundle npm though, so we'd be on our own to grab dependencies from npm. At this time, I don't see a way that Javet simplifies our overall situation, but feel free to open enhancement-request issues or to discuss further here :)

Thank you for the feedback.

Interestingly, I thought the purity of the Node.js mode is a feature rather than a drawback.

1. Managing dependencies belongs to application. npm, yarn, whatever. Javet just loads it in embeded Node.js.
2. Javet doesn't depend on any libraries other than JDK + Node.js + V8. So it deliberately doesn't integrate npm. I also own another project Javenode aimimg at polyfilling V8 mode with Node.js features. That project can depend on more external libraries to provide fancy features.

I did research agaist Embedded Node.js vs. Node.js with gRPC. I have to admit the performance gap is like ~4M calls/s vs. ~10K calls/s. The detailed performance test result is at here. So, I quickly abandoned the idea of making gRPC calls to bring Node.js ecosystem in JVM.

[nedtwigg]

the performance gap is like ~4M calls/s vs. ~300

Wow! At first this seems like a ~10,000x speed improvement, but I think most of our wait time is actually waiting for prettier to finish its calculations within node. Say a project has 1,000 files, we're only making ~1,000 RPC calls anyway, and the reason we're waiting 30 seconds isn't RPC overhead, it's just calculation time within node.

the purity of the Node.js mode is a feature rather than a drawback.

I agree! Especially when you're deploying something, you almost definitely have some packaging/bundling step.

For a dev tool like Spotless, it's a hard requirement for us to say "resolve foopkg@3.0.7 and its dependencies". Right now, that means we need to figure out how to get npm, and if we have that then we also have a matching node distribution with it.

I find managing node/npm to be a nightmare, Gradle does such a great job managing JRE versions for you. Might be an opportunity for JVM-friendly npm-package-resolution library based on your work. One of our worst problems right now is #766, and there's no good reason why it has to be so slow, besides that npm is painful and we haven't taken the time to make it more friendly.

[caoccao]

Yeah, one of the pain points in Node.js is missing libraries.

However, Javet allows Java applications to listen to the module resolve event. Either import { *** } from 'a.js' or require('a.js') can be intercepted. This doc presents how to do that. This Java file is the module resolver in Javenode that supports import { *** } from 'a.js'. So, with Javet, applications may leave npm behind and invent a new way of resolving libraries.

By the way, I think one of the fancy things here is Java applications may resolve that in a multi-threaded manner to speed things up via Javet.

[nedtwigg]

Javet allows Java applications to listen to the module resolve event ... may resolve that in a multi-threaded manner to speed things up

Is there an issue or somesuch I can subscribe to so that I get notified when somebody builds something along those lines?

[caoccao]

Is there an issue or somesuch I can subscribe to so that I get notified when somebody builds something along those lines?

So far, there is no one asking for multi-threaded module resolution. I think mainly because import() is not popular yet as dynamic import can substantially benefit from multiple threads.

Regarding the rest, you may watch Javet and Javenode.