How to Run Java Swing Apps in a Browser Using CheerpJ

Legacy Swing applications still power core processes in many organisations.

Stand-alone Java applications are not straightforward to distribute and update, making for a clunky deployment mode. Java Applet and Java Web start deployment models are deprecated, since modern browsers do not support Java plugins, and Java Web Start was deprecated after Java 8.

If you want to run a Java Swing app in a browser without installing Java on endpoints, CheerpJ provides a direct path that uses your existing code.

This guide explains the approach for enterprise teams that need a predictable way to run a Swing app in a browser and utilise Java code for a browser-based web app without requiring a rewrite.

What CheerpJ Does

CheerpJ runs unmodified Java bytecode in the browser using WebAssembly and JavaScript. No plugins or a local JVM are required. Your users open a URL, and the application starts in the browser. It supports complex desktop-style UIs built with Swing and AWT, Oracle Forms and E-Business Suite, and all Java-based frameworks.

When CheerpJ Makes Sense

Your Swing application is business critical, and a rewrite would be risky or expensive.
Users need direct access in Chrome, Edge, or Firefox without Java on the machine.
You want to reduce the operational overhead of VDI/RDP, or per-device Java installs.
You need a supported path with commercial SLAs.

High-level Architecture

The application JARs and resources are served from your web server or CDN.
The CheerpJ runtime loads in the browser and initialises a Java environment.
Class files are executed client-side. UI is rendered to an HTML5 canvas. Filesystem and networking features are bridged to the browser environment as allowed by policy.

Prerequisites

A build of your Swing application packaged as one or more JARs.
Third-party libraries included in the classpath and deployed with the app.
Access to a static web host or web server to serve the runtime and your assets.
Basic ability to add a small HTML Bootstrap page for the application entry point.

Step-by-step: Running a Swing App in the Browser

For further information, visit the ‘Porting a Swing Application to the Web’ Tutorial in the documentation

Identify the entry point Confirm the main class your users need to launch. Note any JVM args, system properties, or resource paths that the app expects.
Package the application Create a deployment folder that contains your JAR files, resources, configuration files, and any data directories that must be shipped read-only. Keep paths consistent with how the app loads resources.
Host the assets Upload the application folder to your web server or CDN. Place the CheerpJ runtime files in a predictable location that your bootstrap page can reference.
Create a Bootstrap HTML page Add a minimal HTML page that loads the CheerpJ runtime, initialises it, and launches your main class. Keep the page simple and free of blocking third-party scripts. Use rel=preload for large JARs to improve first paint.
Configure storage and downloads Decide how the app should handle files. For example, offer a controlled download flow for exports, and keep user data on the server when required by policy.
Test the application Validate the critical user journeys and any integrations such as printing, networking, or authentication flows. Test your Swing app in a browser on Windows, macOS, and Linux.
Roll out progressively Start with a pilot group, monitor performance and error reports, then roll out broadly using your usual change management process.

Security and Compliance Considerations

Data residency Keep application data where it should be. The browser session only executes client-side code and exchanges data with your existing endpoints, in the same way that your original Java application does.
Access control Use your standard identity provider. Protect app routes behind SSO at the web tier where appropriate.
Updates Ship updates by deploying new JARs on the server, or updating the CheerpJ runtime. Users pick them up the next time they load the page.
Auditability Log server-side activity as you do today. Add client-side error and performance logging to improve triage.

Performance Checklist

Minimise the total size of JARs. Remove unused resources and debug assets.
Serve assets over HTTP/2 or HTTP/3 with compression enabled.
Use a CDN close to users. Preloading JARs might lead to a performance improvement.
Monitor first load time and warm start time from real users.

Operations and Monitoring

Add Real User Monitoring for page load, first interaction, and error rates.
Capture client-side exceptions with context such as browser version and OS.
Track server-side throughput and response times for endpoints used by the app.
Document a rollback plan so you can revert to the previous deployment within minutes.

Common Questions

Does this replace JNLP or Applets? Yes. CheerpJ does not rely on browser plugins. It provides a browser native way to run a Java Swing app in a browser.

Can I still use my existing Java code for a browser web app? Yes. The application runs from your JARs. You use Java code for a browser web app without porting to a new toolkit.

What about printing and file access? Use standard browser print and download flows. File upload is supported with minimal changes to the application.

How do I integrate authentication? Protect the application URL behind your SSO solution. The in-app calls reuse the authenticated session as designed on your server.

Next Steps

If you are ready to put your Swing app in a browser, start with a proof of concept on a representative workflow. Package the app, host the assets, add the bootstrap page, and measure user experience against your current workaround. When you are satisfied, move the rest of the application portfolio.

Get in touch if you need architectural guidance or enterprise support options. This approach lets your teams keep working while you decide whether a full rewrite is worth it later.