Two reasons to bring Java to the browser
You run Java applications. Applets ran through the Java plug-in, and Java Web Start launched applications from a link. Modern browsers dropped the plug-in, Oracle removed Java Web Start from JDK 11, and JDK 26 removed the Applet API itself. Oracle Forms, Oracle E-Business Suite and many internal and vendor applications still depend on them. The applications still do their job; what organisations need is a dependable way to put them in front of users.
You build Java software. Your product has a Swing or AWT desktop client, and your customers want it in the browser: as a SaaS service, on tablets and Chromebooks, on locked-down PCs that cannot install Java, or without an installer to maintain. Or your web application needs a Java library.
The same alternatives come up in both cases, so this page compares them together.
At a glance
| Route | Same app | No install | No per-user server |
|---|---|---|---|
| CheerpJ | Yes | Yes | Yes |
| IE mode in Edge | Yes | No | Yes |
| Desktop launchers | Yes | No | Yes |
| Citrix and VDI | Yes | No | No |
| Streaming | Yes | Yes | No |
| Compilers | No | Yes | Yes |
| Rewrite | No | Yes | Depends |
The alternatives
IE mode in Edge
IE mode keeps the Java plug-in working by opening the page with Internet Explorer’s engine, alongside a Java installation on every Windows desktop.
- Benefits: no work on the application, and Microsoft supports IE mode through at least 2029.
- Drawbacks: a Java installation on every Windows desktop, an old browser engine kept alive, and an end date set by Microsoft with a year’s notice.
Desktop launchers: OpenWebStart, IcedTea-Web and the Forms Standalone Launcher
Launchers replace Java Web Start and the plug-in with a locally installed launcher and Java runtime.
- Benefits: close to the original Web Start experience on managed desktops.
- Drawbacks: a Java runtime on every device to package, patch and audit, no browser access, and nothing for tablets, Chromebooks or locked-down PCs.
Citrix and VDI
Citrix Virtual Apps and Desktops, Microsoft Azure Virtual Desktop and Omnissa Horizon run the application on a server inside a remote desktop session, which users reach through a remote desktop client or a browser.
- Benefits: runs almost any application, including non-Java software, under central control.
- Drawbacks: a second platform to license and operate, servers sized for every concurrent user, and a whole remote desktop to reach one application.
Server-side streaming: Webswing, Vaadin SwingBridge and JPro
Webswing and Vaadin SwingBridge for Swing, and JPro for JavaFX, run the application in a Java process on a server for each user session and stream its interface to the browser.
- Benefits: the application runs unchanged on a server and appears in the browser.
- Drawbacks: a Java process on your servers for every user session, every interaction travels over the network, and user data passes through the server.
Compilers to JavaScript and WebAssembly: GWT, J2CL, TeaVM and GraalVM Web Image
These tools compile Java source or bytecode ahead of time into JavaScript or WebAssembly, which then runs without a Java runtime.
- Benefits: small, fast JavaScript or WebAssembly with no Java runtime.
- Drawbacks: they need the source code, cover only part of the Java class library, have no Swing or AWT, and limit reflection and dynamic class loading.
Rewriting, including Oracle APEX
A rewrite replaces the Java client with a new web application, built with a web framework such as React or Angular, or, for Oracle Forms, with Oracle APEX.
- Benefits: a web application designed from scratch.
- Drawbacks: usually the longest and most expensive route: years of work, every existing feature to match, and two applications to maintain until it is done.
CheerpJ
CheerpJ is a Java runtime built from OpenJDK and compiled to WebAssembly. It runs the application’s existing JAR files in the browser tab, on the user’s device, with nothing installed and no server running Java.
- Benefits: the same application and JARs, in any modern browser, on any device, with no server running Java.
- Drawbacks: the first visit downloads the parts of the runtime the application needs, so start-up is slower than on later visits.
Why CheerpJ, for Java applications you run
CheerpJ retires the infrastructure that only exists to keep Java running, and keeps the application.
- No IE mode and no Java on the desktop. The application runs in Chrome, Edge, Firefox or Safari, inside the browser sandbox, so there is no Java runtime to package, patch or audit on any device.
- No remote desktop for one application. Users open the application in their browser, and it runs on their device, so there is no server to size for concurrent users and no remote session to manage.
- No change to the application. Oracle Forms, Oracle E-Business Suite, applets and Java Web Start applications run from their existing JARs, and Forms servers and databases stay as they are.
- Two ways to deploy. The CheerpJ Applet Runner and JNLP Runner extensions need no server changes and deploy through Group Policy, or CheerpJ Core can be added to the page that launches the application, for every browser.
Why CheerpJ, for Java software you build
CheerpJ turns your Java desktop client into a web application from the same codebase, without a rewrite and without a server for each user.
- Same codebase, current Java. Your Swing or AWT application runs from the JARs you already ship, on Java 8, 11, 17 or 21, with Java 25 in preview, and each new Java LTS release is added as it comes out.
- Client-side, unlike streaming. The application runs on the user’s device, not in a Java process on your servers, so you do not provision servers for every concurrent user, the interface responds without a round trip, and user data stays on the device.
- The whole of Java, unlike compilers. CheerpJ runs the OpenJDK class libraries on a real JVM, so Swing, reflection, threads, dynamic class loading and third-party libraries work, and you do not need the source of every dependency.
- Any device and any distribution model. The web edition runs on Windows, macOS, Linux, ChromeOS, Android and iOS, and it ships as static files: as a SaaS service, to customers who host it themselves, or on air-gapped networks.
- Java libraries in web applications. JavaScript and TypeScript can call Java libraries directly, client-side, with no backend.
What CheerpJ includes
- Java built from OpenJDK. Java 8, 11, 17 and 21, with Java 25 in preview. Each version is a full build of OpenJDK, not only the JRE subset, with OpenJDK’s native code compiled to WebAssembly.
- The whole language and bytecode. Reflection, proxies, custom class loaders, and encrypted or obfuscated JARs.
- Desktop features. Swing, AWT and Java2D, files through a virtual file system with uploads and downloads, printing through the browser, the clipboard, audio, fonts and international text.
- Networking. HTTP and HTTPS through the browser, and TCP and UDP through Tailscale or a custom networking backend.
- Native code. Application native methods implemented in JavaScript or compiled to WebAssembly.
- Java and JavaScript together. Library mode for calling Java from JavaScript, and native methods for calling JavaScript and browser APIs from Java.
- Mobile and touch. Touch input and virtual keyboards on phones and tablets.
- Self-hosted and private. Static files on any web server or CDN, including air-gapped networks. The enterprise build contacts no external server, with no licence server and no telemetry.
The compatibility page has the details, and the resource preloading guide explains how to shorten the first start-up.
When another route fits better
CheerpJ covers most Java client applications. A few specific cases are better served elsewhere for now:
- Applications built on JavaFX are not supported today. JavaFX support is planned for 2027; until then, server-side streaming such as JPro or Webswing can deliver them.
- Eclipse RCP and other SWT applications are not supported.
- Applications whose core is a pre-built native binary, such as a Windows DLL with no source code available, cannot run in any browser. Native code with source can often be compiled to WebAssembly.
- Non-Java software delivered through Citrix or VDI still needs that platform. CheerpJ removes the Java applications from it.
Not sure where your application fits? Request a compatibility review and our engineers will tell you.