Live data from Hacker News

CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers

leaningtech.com

11–20 of 179 posts

Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers

#11

Earlier quoted context omitted.

In the case of CheerpJ the virtual machine itself is pure C++ compiled to WASM, but the JIT-ted code and the objects are pure JS. Garbage collection is natively handled by the browser. As WASM GC stabilizes we will consider supporting it as well.

Ah, this is an interesting approach. Does JITing over to JS introduce problems with concurrency support though, given the lack of threads in the JS runtime?

JS does have thread.

Worker on the client side:

https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...

Server-side/nodejs: https://nodejs.org/api/worker_threads.html#worker_threads_wo...

Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers

#12

I was hoping to see an AOT - but they say that currently it is just interpreter + JIT. This is beneficial for compatibility but counterproductive for speed. Nevertheless, an interesting project.

There is TeaVM though which is AOT https://github.com/konsoletyper/teavm

Google's J2CL (successor to GWT) is also AOT.

https://github.com/google/j2cl

Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers

#16

Neat Strikes me though that all these "managed-memory language VM inside a a WASM VM" projects for WASM keep having to build out garbage collection support (or run an existing GC inside WASM) for their runtimes. It's a bit of a stacking turtles problem, and seems wildly inefficient. I keep wondering how far off GC support for WASM runtimes is. In the meantime, while this is neat, I feel like it's a mis-use of what WA…

WASM Garbage collection is coming pretty soon. Currently, it's behind a feature flag in Chrome. I think the chrome flag for GC is due to be removed in a few months. I don't know when Firefox and Safari will roll out support. But I assume they won't be that far behind.

One of the things I'm following that will use garbage collection support is the Kotlin wasm compiler which is currently available as an experimental option with kotlin 1.8 and beyond. And of course with wasmer and wasmtime, it will also be possible to target edge computing with this eventually (as they roll out gc support in the next months). Fair warning, this stuff is very cutting edge currently. Wait six months or so for this to become more usable. The upcoming kotlin 2.0 is probably going to be seeing some usable early access version.

There is already some experimental wasm support for Jetpack Compose multiplatform in the works as well. Currently you'd mostly use the kotlin-js compiler for that on the web but pretty soon you should be able to compile to wasm instead. This will work both with components that render to a canvas as html based web components. Advantages of kotlin wasm over kotlin-js: faster compilation and loading speeds. And having used kotlin-js, faster compilation speeds are very much welcome.

If you are into multiplatform UI development, another thing that is interesting with this is the IOS support in compose. So with compose you should be able to target Android, IOS (native), Web (js and wasm) and desktop (jvm). Interesting new framework with not a lot of alternatives beyond react native and Flutter so far. And of course Kotlin is popular on Android and for cross IOS/Android development already. This stuff will take some time to mature but there was a lot of buzz around this topic at kotlin conf a few weeks ago. And of course with wasm and wasm components, you'd be able to do cross platform UI development and integrate the same components via wasm on each platform rather than having to engineer bespoke components for each platform.

Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers

#17

On the flip side, is there a JVM-based Wasm interpreter? JNI is great and all, but I love the thought of compiling native code to WASM to provide a single package for all plaform without extra redundant packages.

Yes, and it will JIT compile the code to native if you're using GraalVM:

https://github.com/oracle/graal/tree/master/wasm

But the point of JNI is to provide language bindings. WASM doesn't automatically fix the need for those.

Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers

#18

Earlier quoted context omitted.

There is TeaVM though which is AOT https://github.com/konsoletyper/teavm

Google's J2CL (successor to GWT) is also AOT. https://github.com/google/j2cl

J2CL sadly uses Java sources as the input, not JVM bytecode, which makes it hardly usable for a lot of use cases involving existing libraries.

Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers

#19

I was hoping to see an AOT - but they say that currently it is just interpreter + JIT. This is beneficial for compatibility but counterproductive for speed. Nevertheless, an interesting project.

There is TeaVM though which is AOT https://github.com/konsoletyper/teavm

And Bytecoder which targets Wasm GC. https://github.com/mirkosertic/Bytecoder

Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers

#20

On the flip side, is there a JVM-based Wasm interpreter? JNI is great and all, but I love the thought of compiling native code to WASM to provide a single package for all plaform without extra redundant packages.

Maybe embed wasmtime? I'm familiar with https://github.com/bytecodealliance/wasmtime-dotnet but perhaps this for jvm? https://github.com/kawamuray/wasmtime-java/blob/master/examp...

I too love the idea of embedding wasm modules to be used across platforms.

Post reply on HN