Shameless plug: CheerpJ is our solution to run any JVM language in the browser, including Clojure. Reflections, Multithreading and Swing / AWT apps are all supported.

https://labs.leaningtech.com/blog/cheerpj-4.0

And yes, it can run Minecraft :-)

https://browsercraft.cheerpj.com/

The more the merrier.

With CheerpJ you are downloading the subset of the JVM that you need, and actually only once thanks to the standard browser cache.

There are many reasons why shipping via the browser is a better choice compared to shipping desktop apps. The main 3 in my opinion are:

1. Distribution: Give your user a link and the app will start 2. Isolation: The user can have confidence the app won't read his personal files. 3. Cross-platform: Every OS and every device, for real this time

For reference, when loading https://browsercraft.cheerpj.com for the first time (up to loading a world), my browser downloaded ~32MB.

The second time almost nothing.

And here's an entire Java IDE with CheerpJ that downloads less than 15mb:

https://reportmill.com/SnapCode

> With CheerpJ you are downloading the subset of the JVM that you need

That's interesting! May I ask how it works? Does that also happen with e.g. IntelliJ?

> Every OS and every device, for real this time

Doesn't the JVM run everywhere in 2025?

> That's interesting! May I ask how it works? Does that also happen with e.g. IntelliJ?

Byte ranges request do most of the heavy lifting, data is loading exclusively on-demand.

> Doesn't the JVM run everywhere in 2025?

What about iOS? Android has Java, but can't run desktop Java apps. Chromebooks also have limits.

> Byte ranges request do most of the heavy lifting, data is loading exclusively on-demand.

I don't understand what that means. The JVM is supposed to interpret and sometimes compile bytecode, right? How can it be done with only a fraction of the JVM?

Or are you saying that it is constantly communicating with a server that does the work?

The VM itself is very small, it's the OpenJDK runtime that is quite sizeable. Byte ranges are used to only download the parts of the runtime (in terms of bytecode) that are required.

There is no server-side computation. CheerpJ runs code exclusively client-side.

But you said before that you only download a subset of the JVM, right? Or did you mean a subset of the JDK, including the JVM and... I guess other stuff?

I meant the JVM in an extended sense: the combination of the bytecode parsing, JIT compiler and OpenJDK runtime. You are right, I should have been more precise and refer to only the runtime part, which is by far the most significant.

I was not trying to prove you wrong, I'm just genuinely interested :-). I don't see a lot of articles about the JVM these days.

No, this is the unmodified Minecraft JAR running on top of CheerpJ, a WebAssembly-based JVM.

Hi everybody, happy to see our CheerpJ demo is appreciated.

CheerpJ is a WebAssembly-based JVM that can run unmodified Java 8 and Java 11 applications. Java 17 will be supported later in year.

I am the lead developer of CheerpJ and CTO of Leaning Technologies. AMA.

Cool stuff!

Hey I saw a typo on https://cheerpj.com/cheerpj-core-licenses/, it says "liencesees" halfway the page

Thanks for spotting this, we'll get it fixed ASAP

Would it work for a JavaFX app? (not sure I'd be able to shrink the bundle size enough for it to make sense though)

JavaFX is not yet supported, but we plan to get it to work soon.

The issue here is that there is very little Java in JavaFX, it's mostly native C++ code. This makes it actually quite similar to the LWJGL library used by Minecraft.

Our plan is to use for JavaFX the same technology we have developed for LWJGL.

thanks! that's kinda what I figured. And now it's not part of Java's "core" so it'd make sense if it was "out of scope"

How much is the licensing for a small company wanting external users to use it to use an app hosted online?

Small Business licenses will be available with the release of CheerpJ 4.0, expected in mid April 2025.

They will allow self-hosting and will be priced on a per application / per website basis. They will be priced to be affordable and ensure that CheerpJ enjoys a wide reach.

If you are interested before the release, please do get in touch (info@leaningtech.com).

This is actually running on top of a WebAssembly-based Java Virtual Machine (CheerpJ).

You are probably thinking about our independent x86 virtualization product CheerpX (https://cheerpx.io)

No, I'm thinking about porting the Linux kernel to WASM itself and not using a VM written in WASM but WASM directly:

https://wasmlinux-demo.pages.dev

In other words, using WASM as if it were the CPU architecture in the VM.

Mobile is indeed supported, although the performance is not yet as nice as we would like.

The trickiest issue is input, since the "look around with your mouse" interaction maps very poorly on a mobile platform where "mousemove" implies touching / clicking.

We plan to eventually figure out a mobile-optimize UX, but we will most likely prioritize improving the performance first.

Thanks for your kind words, appreciated.

Link to our blog, we try to regularly publish high quality content: https://labs.leaningtech.com/blog

> Chromium is open source, with contributions from many organizations (who retain the copyright to their contributed code).

To contribute anything to Chromium or V8 you need to sign a CLA, afterwards there are very little rights you retain.

The CLA just gives Google a license to use the code your contribute (and a license to any associated patents). You still own the copyright, and Google cannot sell the rights to your code.

https://cla.developers.google.com/about/google-individual

You can play with an online simulator of this machine here: https://davidsharp.com/baby/online/index.html

The simulator is originally written in Java, and the browser version is powered by CheerpJ, a WebAssembly-based JVM (https://cheerpj.com/)

Benjamín Labatut - The Maniac, a novelized biography about the mathematician and computer science pioneer John von Neumann.

The story of his life was absolute fascinating for me, unfortunately the last part of the book attempts a connection with the development of Alpha Go / reinforcement learning that should have been avoided.