I Put a Full JVM Inside a Browser Tab
27 points by juliethefoxcoon
27 points by juliethefoxcoon
Time is a flat circle.
Applets without the browser plugin? neato.
This is a cool experiment and a nice learning experience. I don't like to shill on someone else's post, but:
We’re exploring using JavaBox for a Java documentation site. The idea is that when you’re> reading about, say, HashMap or generics or whatever Java concept, there would be a “Try It” button right there on the page. Click it. Edit the example code. Hit run. See the output. No installing a JDK. No setting up an IDE. No server processing your code somewhere.
And
The other idea is shareable snippets. You write some Java, get a URL, send it to someone. They open it and the code runs in their browser. No backend to maintain. No server costs that scale with users. Every user’s browser is doing its own compute. It’s serverless in the most literal and also most ridiculous sense of the word.
You can do these today with CheerpJ
See this sharable snippet with a Swing application for example
Disclaimer: I work on CheerpJ
Disclaimer: I work on CheerpJ
Nice to see this! I looked at CheerpJ a few years when I dug out an open source game I had written a long time ago. I ended up rewriting it but was intrigued. I do wish there were an option for self-hosting for open source projects.
Oracle GraalVM 25 supports a --tool:svm-wasm option to compile things into WASM, and they currently have a javac on WebAssembly demo (which downloads a 30 MB WASM blob). I wonder if one can also compile TeaVM or Espresso to WASM for a Java playground, which hopefully should be faster than a JVM over QEMU over WASM. But regardless, it's quite crazy what container2wasm can do these days, as is demonstated in the post.
Edit: Just found TeaVM's playground allowing you to compile Java code and run them in the browser.
You don’t get hotspot with that though I think? So no JIT, I’d argue this doesn’t qualify as “full JVM”
I don't think JIT is a precondition for JVMs: any implementation that can run Java bytecode according to the JVM specification should still qualify as a JVM, even if it only interprets the code. For example, OpenJDK also provides a --with-jvm-variants=zero build option to build an interpreter-only JVM; it's still a fully functional JVM, just not a full "OpenJDK". (Also, the blog post explicitly opts out of JIT with -Xint.)
When targeting something like x86_64, in a GraalVM Native Image with Espresso (a JVM implemented using Truffle) or any other Truffle language, the native executable includes the Graal compiler to implement JIT, so you can get a full JVM with JIT in a native image (as a "guest language").
However, I doubt --tool:svm-wasm supports any kind of JIT because I don't think Wasm has good support for modules doing the fine-grained runtime code generation you'd need for a JIT (though some have experimented with the idea), so you'd be right for that reason.