OpenJDK and the End of Java Web Start: What Are Your Options?
15 October 2025
Most organisations have already picked a stopgap when browser plugins disappeared. You probably moved to Java Web Start and installed Open WebStart, pushed users through VDI or RDP, or started a rebuild.
This post assumes you are in one of those three camps and explains why, if you moved to Java Web Start, moving to the CheerpJ JNLP Runner is often the better long-term choice for practical OpenJDK web deployment and a secure, modern browser-based user experience.
What changed
- Oracle deprecated Java Web Start years ago, with the release of Java 9. This anchored the use of Java Web Start to Java 8, preventing the update to more modern versions of the JRE.
- OpenJDK distributions usually do not include a Web Start implementation, which needs to be provided separately.
- Alternatively, use of Oracle Java 8 does provide a supported Java Web Start implementation, but comes with the requirement of installing Oracle Java.§
Result: to preserve the application’s functions, either a rewrite, the replacement of Java Web Start with an alternative launcher, or accepting to use an external Web Start implementation are the only alternatives to Oracle Java.
Where most organisations are today
1. Open WebStart on the desktop
What you did: installed a JNLP client on endpoints and kept using JNLP descriptors.
Common issues: per-device installs, version drift, packaging and patching overhead, and user support tickets for updates.
2. VDI or RDP
What you did: centralised the Java runtimes and Web Start implementations on managed Windows hosts and delivered access over remote sessions.
Common issues: ongoing infrastructure cost, latency, print and file redirection problems, and poor fit for mobile or field users.
3. Rebuild in a modern web stack
What you did: started a multi-quarter project to redesign and reimplement the client.
Common issues: delivery risk, scope creep, loss of edge cases, and long lead time before users see benefits.
Why CheerpJ is a better long-term choice
CheerpJ runs unmodified Java bytecode in the browser using WebAssembly and JavaScript. The CheerpJ JNLP Runner is a simple browser extension that interprets JNLP files, and launches Java Web Start applications in Chrome, Edge, or Firefox. No local Java. No plugins. Execution is completely within the browser tab.
Side-by-side comparison
| Area | OpenWebStart | DI or RDP | Rebuild | CheerpJ JNLP Runner |
|---|---|---|---|---|
| Requires an installation on the end-user Desktop | Yes | No | No | No |
| Browser access | Indirect, desktop launcher | Indirect, remote session | Native after delivery | Native |
| Time to value | Fast, but ongoing care | Medium | Slow | Fast |
| Ongoing cost | Medium: Device management and support | High: Infra, licensing, ops | Very High | Low to medium |
| UX and performance | Original UX, original performance | Original UX, low performance and high latency | Good after delivery | Original UX, close-to original performance |
| Risk | Low technical, high support | Medium technical, high ops | High delivery | Very low |
Migration paths from current setups
From OpenWebStart to CheerpJ Applet ERunner
- Keep your JNLP descriptors. Access them from the e CheerpJ JNLP Runner for browser launch.
- Remove per-device installs of OpenWebStart as adoption grows. Manage a short overlap period.
From VDI or RDP
- Redirect access to the application from VDI to direct browser access from the Desktop.
- Make sure that end-user browsers have the CheerpJ JNLP Runner installed
- Pilot with a group, then distribute the CheerpJ JNLP runner to the entire fleet, and retire remote sessions for that app.
From an active rebuild
- Use CheerpJ to stabilise current users in the browser.
- Reduce pressure on the rebuild timeline. De scope or phase features based on real usage.
Triggers that suggest it is time to switch
- Helpdesk tickets about OpenWebStart installs and updates.
- Latency complaints or print issues from VDI or RDP users.
- Rebuild dates slipping or scope expanding.
- Audit findings related to local JREs or unmanaged Java components.
Security and compliance
- Use existing SSO and network controls. Protect routes at the web tier.
- Keep data on the server. The browser session executes client-side code and calls your APIs.
- Log server side as you do today. Add client-side error reporting for triage.
- Reduce JRE footprint on endpoints to lower patching and audit work.
Frequently asked questions
Does this work with OpenJDK on the server? Yes. CheerpJ executes Java bytecode in the browser and integrates with your OpenJDK server-side stack. Verify target JDK versions and libraries during evaluation.
Does this work with Oracle Java on the server? Yes. CheerpJ is also compatible with Oracle Java server-side stack.
How does printing and file download work Use standard browser printing and controlled download flows. File downloading and uploading work as standard.
What performance should we expect? Near-native execution time, and a slightly slower startup time compared to native, due to the network layer.
How do we start a pilot? Pick one JNLP workflow, install the extension at no cost, with no restrictions, e, and run a limited user test. Deploy a production build to a limited number of users. Compare support tickets and performance to your current method.
Summary
If you need to replace Java Web Start, and/or you already rely on OpenWebStart, VDI or a rebuild, evaluate CheerpJ. It delivers practical OpenJDK web deployment with a real JNLP browser experience, no desktop installs, and a faster route to value.