CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
1–10 of 179 posts
Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
#2> multithreading
... but can it actually use multiple cores without limit, like the JVM itself?
Is it a bug or a feature that I can not move the swing window despite it having a top-bar and closing X button?
Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
#3Neat
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 WASM is most suited for: cross-compiling C/C++ etc binaries to a "web" target. WASM as a container for multiple language runtimes seems wildly inefficient.
Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
#4> multithreading ... but can it actually use multiple cores without limit, like the JVM itself? Is it a bug or a feature that I can not move the swing window despite it having a top-bar and closing X button?
Window movement is implemented in the current production release (CheerpJ 2.x), but not yet as part of the CheerpJ 3.0 rework.
Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
#5I 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.
Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
#6Neat 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…
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.
Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
#7I 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
Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
#8Neat 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…
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?
Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
#9I 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.
In article they explain, that previous version (CheerpJ 2.0) used AOT, but "CI setup was often felt as an unwelcome burden, and many of enterprise users found it hard to run the actual AOT compiler binaries on their controlled environments". So they decided to go to interpreter + JIT instead of AOT...
Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
#10> multithreading ... but can it actually use multiple cores without limit, like the JVM itself? Is it a bug or a feature that I can not move the swing window despite it having a top-bar and closing X button?
RE Multithreading: just tried this:
public class JavaFiddle {
public static void main(String[] args) {
new Thread(() -> System.out.println("Hello World from another thread!")).start();
System.out.println("Hello World!");
}
}