Leaning Technologies has recently released CheerpJ 4.3, a maintenance-focused update to their WebAssembly-based JVM for the browser. If Chicory Redline last week represented Wasm coming to the JVM - a plain JAR for embedding Wasm inside Java applications - CheerpJ is the inverse movement, and has been since 2018: the JVM packaged as Wasm so Java applications can run unmodified in a browser.
4.3 is a small release, and the team's own framing is the right one for reading it: 5.0 is the next major milestone, but enough quality-of-life improvements accumulated that sitting on them until then didn't make sense. 4.3 is scaffolding shipped in good faith, not a feature release trying to be bigger than it is.
What 4.3 Actually Ships
Filesystem ergonomics get most of the attention. Every decorated Java window now has an upload icon in its title bar, letting end users pull a local file into CheerpJ's virtual filesystem without any JavaScript glue on the host page. On the export side, a new /files/downloads/ virtual directory auto-downloads anything written to it. Small changes, but they close the gap where previously you had to write JavaScript to bridge the browser and the Java runtime for basic file I/O.
Mobile gets a real improvement: long-press gestures are now interpreted as mouse hover events. This matters specifically because native Swing menus expect hover to navigate submenus, and touchscreens don't have hover. Anyone who has tried to use a Swing application on a phone will recognize the problem.
The Java 11 and 17 runtimes continue to gain stability and performance improvements, with the FlatLaf demo now running smoothly - a reasonable indicator that the runtimes are production-ready rather than demo-ready.
What CheerpJ Actually Runs
Java 8 support looks like legacy courtesy until you notice that's specifically what applets and Java Web Start require. Browser plugins died between 2015 and 2018 - Chrome removed NPAPI, Firefox followed, and every Java applet and JNLP-launched application built for that delivery model was suddenly unreachable from a modern browser. The applications themselves didn't go anywhere, and some environments demand their function, like some legacy banking rules required by law.
CheerpJ runs them. Applets work without a plugin because CheerpJ is the plugin, compiled to WebAssembly. JNLP applications launch through CheerpJ's JNLP Runner. Leaning Technologies ships browser extensions for both, aimed at users who don't want to think about hosting - point the extension at the applet or JNLP URL and it runs.
This is what explains the enterprise names on CheerpJ's overview page - NASA, Siemens, UBS - and the specific mention of Oracle Forms and EBS in the compatibility footnote. Organizations with large installed bases of Oracle Forms applications, internal JWS tools, and legacy Swing clients have been stuck with uncomfortable options: migrate off Java (a multi-year investment, plus abandonment of a strong and proven platform), keep a legacy browser around (a security nightmare), or wrap everything in a VDI. CheerpJ is a fourth option that doesn't require touching the application.
The 4.3 filesystem and mobile improvements serve this audience directly. An Oracle Forms application running via CheerpJ on a tablet, with working menus and working file uploads, is a meaningful capability for a field-deployed workforce.
How CheerpJ Actually Works
"WebAssembly-based JVM" invites a natural assumption: the JVM runs in Wasm, Java objects live in Wasm linear memory, everything is Wasm all the way down. CheerpJ's architecture is more subtle than that, and the subtlety matters for reading the rest of the story.
The JVM implementation - class loading, reflection, the interpreter, JIT machinery - is written in C++ and compiled to WebAssembly via Cheerp, Leaning Technologies' own C++-to-Wasm compiler and the tool the company was originally built around. But the JIT target isn't more Wasm. CheerpJ's JIT compiles Java bytecode to optimized JavaScript, which the browser's JS engine then JITs again to native code. The architecture is a two-tier execution model - interpreter for cold code, JIT-to-JS for hot code - riding on top of whatever JavaScript engine the browser already ships.
The consequence is that V8 and SpiderMonkey's garbage collectors are managing Java objects directly. CheerpJ isn't shipping its own GC for the hot path; the browser is. This is why the team has said WasmGC isn't necessary for satisfactory hot-path performance - that decision was baked in the moment the JIT chose JavaScript as its target. The pragmatic bet there is that browsers already ship production-grade memory management for dynamic code, and CheerpJ just has to get the code to a form the browser can optimize.
WasmGC has nonetheless moved up the priority list for 5.0, for a different reason than the hot path: boot time. They say that their enterprise customers - the Oracle Forms and internal Swing tools users - care much more about a large application starting in twenty seconds instead of thirty than about another Java LTS version landing on schedule. That feedback has pulled WasmGC forward, potentially ahead of Java 21 parity in the short term. It's still an internal implementation detail from a user's perspective, but it's no longer a "maybe someday."
It's a play Leaning Technologies has been running for a while. Cheerp came first; CheerpJ and CheerpX emerged from the realization that virtualizing compiled binaries reached far more real-world software than a source-first compiler ever could. The Linux syscall emulation layer built for CheerpX is also what recently let them ship BrowserPod, a Node-and-Python-in-the-browser sandbox in the same family (although it's actually a universal sandbox - it just points out Node and Python explicitly.) CheerpJ is one expression of a broader "browser as general execution substrate" bet, not a one-off port.
The 5.0 Question
CheerpJ's publicly stated roadmap, from their February 2025 announcement, targeted LTS parity by the end of 2026: Java 11 and 17 in 2025, Java 21 in 2026, with CheerpJ 6.0 eventually offering all four LTS versions as selectable runtimes. 4.3 ships with 8, 11, and 17.
That plan is actively adapting. Enterprise feedback has pushed WasmGC and startup performance up the list, potentially at the expense of Java 21 parity in 5.0. The customers running Oracle Forms and legacy Swing clients aren't asking for pattern matching and virtual threads; they're asking for large apps to boot faster. Whether 5.0 ships Java 21 or leans into WasmGC first is a live question rather than a settled one.
Beyond language versions, the roadmap includes JavaFX support, SWT support, accessibility improvements, and continued expansion of the JNI module system introduced in 4.0. JavaFX is probably the highest-leverage of those for the enterprise market - a significant installed base of modern Java desktop applications uses JavaFX rather than Swing, and "CheerpJ runs my Swing app but not my JavaFX app" is a real gap for a subset of customers.
Practitioner Notes
The iText client-side PDF generation example in the release post is a compelling demonstration of Library Mode, CheerpJ's JavaScript-to-Java interop surface. It uses iText 5.5.13.3, which is AGPL/commercial dual-licensed. Anyone copying that code into a closed-source commercial product has a licensing problem that has nothing to do with CheerpJ and everything to do with iText — worth knowing before the integration gets far.
The runtime actually downloads modules as it runs, which means that you don't have a monolithic deliverable, too - a fundamental aspect of performance. An IDE written with CheerpJ like SnapCode downloads bits and pieces as needed - noticeable if you're watching but still performing quite acceptably.
The /files/ mount is backed by IndexedDB, which means persistent storage is subject to the browser's quota policies and eviction behavior. That's fine for session state and user-generated documents, not a substitute for server-side persistence, but it's not intended to replace server-side persistence.
CheerpJ is commercial software, free for FOSS projects, personal projects, and one-person companies; everyone else needs a license.
Worth Watching
4.3 is a good release for its intended audience: existing users running applets, JNLP applications, Oracle Forms, and Swing clients in the browser, who benefit from the filesystem and mobile improvements without waiting for 5.0. That market is mature, well-served, and still ships on Java 8.
For the second market - modern browser-native Java as a first-class platform - the watch items are which tradeoffs 5.0 actually makes: Java 21 parity versus WasmGC-driven startup wins, JavaFX to broaden desktop-app coverage, continued JNI expansion. The underlying architecture is more pragmatic than the "WebAssembly-based JVM" label suggests, and the team has been letting enterprise feedback reshape the stated plan rather than adhering to it for its own sake.