CheerpJ compiles a Java runtime to WebAssembly and runs it in the browser

What the thing actually is

CheerpJ is a WebAssembly-based Java virtual machine for the browser, with extensive compatibility with Java 8, 11 and 17, and it provides a full runtime environment for running Java applications, applets, libraries and Java Web Start or JNLP applications in the browser without plugins. The list of things it claims to do is short and each one is a real product problem. Run existing Java applications in the browser with no changes. Include Java applets in webpages without legacy plugins. Migrate Java Web Start and JNLP applications so they work on modern systems, which is the case for every organisation that deployed an applet or a desktop shortcut back in the 2000s and has been living with the consequences since. Use Java libraries from JavaScript or TypeScript seamlessly. And interoperate between Java and JavaScript libraries in both directions. The current version badge is 4.3, and the whole thing loads with a single script tag.

<script src="https://cjrtnc.leaningtech.com/4.3/loader.js"></script>

The architecture is a JIT compiler plus a real runtime

The how it works section gives the composition, and it is the part that explains the capability. CheerpJ is a combination of two components: an optimising Java-to-JavaScript JIT compiler, and a full Java SE 8, 11 and 17 runtime based on OpenJDK. Both are written in C++ and are compiled to WebAssembly and JavaScript using Cheerp, which is the same compiler toolchain the vendor uses for its other projects. The runtime is the important half, because it is a full runtime rather than a subset, and it is based on a full OpenJDK runtime environment with networking, a virtualized filesystem, clipboard access, audio, printing and Swing and AWT support. The footnote at the bottom of the readme is the honest qualifier, and it says CheerpJ has been tested on Oracle Forms, EBS, Swing, AWT and numerous frameworks and libraries, and that it should be able to run Java SE applications that you would otherwise need a Java Runtime Environment for.

Six claims about what makes it different

The what is unique section lists six points, and the first one is the one that decides whether the tool applies to you. Extensive support for Java 8, 11 and 17, including Swing, reflection and dynamic class loading, with no manual intervention on the code. The second point is the practical consequence: CheerpJ works directly on Java bytecode and does not require access to the Java source code. That is what separates it from the approach of compiling a Java application to JavaScript ahead of time, which needs the sources and produces a bundle tied to one build of one application. Working on bytecode means you can point it at a jar you already have, including a jar whose source you do not have, which is exactly the situation for a legacy application or a third-party product such as an Oracle Forms deployment.

The performance and interop claims

The remaining points cover the engineering. The runtime supports WebAssembly for optimal performance and size, which is the reason the JVM itself is compiled to WebAssembly rather than interpreted. The JavaScript code generated by the CheerpJ JIT is highly optimised and garbage-collectible, which matters because the alternative is a JavaScript heap that grows without the discipline the JVM would apply. Bidirectional Java and JavaScript interoperability is the fifth point, and it is specific: JavaScript libraries and the DOM can be called and manipulated from Java, and Java modules can be invoked from JavaScript, which is the property that makes it usable as a library tier rather than only as an application host. The sixth is multithreading, where CheerpJ supports Java multi-threading and you can create concurrent applications by using Web Workers, which is the browser's answer to the thread-per-request model the JVM expects.

The repository is documentation, samples and a Discord server

The repository itself is thin, and that is worth saying plainly rather than hiding. The top level is a README.md, an assets/ directory holding the logotype and an explanation diagram, and an examples/ directory. The examples are the substance, and each one targets a different capability: an applet example called FoilSim-Applet, a Pitch-Applet example, an Interoperability example, a Server-Client example, a Swing-Browser example and SwingSet3, plus a README for the examples directory. A project whose repository is a readme and a set of samples is a project whose real code lives elsewhere, and the links out confirm it, with the documentation at labs.leaningtech.com, the examples in the repository, an issues tracker and a Discord server. The demos are hosted on the vendor's own site, and the two public ones are JavaFiddle, which is a Java playground in the browser, and Browsercraft.

Who is using it, and what it costs

The community section names the production users, and the list is the strongest evidence in the readme: CheerpJ is used in production by teams at NASA, Siemens, UBS and many others, with a case studies link. That is a meaningful claim for a tool that runs a JVM in a browser, because the failure mode of such a tool is a page that silently falls over on a specific browser or a specific legacy application. The licensing is where the catch is, and it is the first thing to check. CheerpJ is free for personal use and technical evaluation, with details on a licensing page. For an organisation running it in production, which is what the named users are doing, there is a commercial arrangement, so the free tier is for evaluating rather than for deploying.

Where this is the wrong choice

Three limits are worth naming. The first is that this is a compatibility layer, not a migration path. It lets an existing Java 8 application keep running in a browser without plugins, which solves a problem that exists because applets and Java Web Start were deployed in the first place, but it does not make that application maintainable, and a team that has the source code is usually better served by rewriting the front end. The second is size and start-up cost, since a full OpenJDK runtime compiled to WebAssembly is not a small download, and the single script tag hides how much is behind it. The third is the boundary of the runtime, which is real but not total: the footnote's phrasing, that it should be able to run Java SE applications, is a hedged claim rather than a guarantee, and the compatibility with Java 11 and 17 is described as extensive rather than complete. For an Oracle Forms deployment with no source code and a hard requirement to keep working, none of that matters much. For anything with a choice, it is worth comparing against a server-side API.

Editorial conclusion

CheerpJ suits a team with an existing Java 8 application or an Oracle Forms deployment that has to keep running in a browser without plugins, and it suits anyone who needs a Java library callable from JavaScript. It is the wrong tool for a new Java application, because a JavaScript or TypeScript front end with a server API is the cheaper answer, and it is the wrong choice if you need commercial use without paying, since the licence is free for personal use and technical evaluation only. Before adopting it, read the licensing page and the compatibility footnote, because the support for Java 11 and 17 is not the same as full support for those platforms, and check the examples rather than the feature list, since the repository itself is mostly documentation and samples. The last push was on 2026-06-12 and the repository publishes no releases.

Frequently asked questions

Official sources

1. Issues
2. leaningtech/cheerpj-meta on GitHub
3. Project website
4. README