Compatibility

Java versions

• Java 8, 11, 17 and 21, Java 25 (preview)
• A commitment to support future Java LTS releases
• 100% of the Java language and bytecode, including reflection and other complex constructs that Java-to-JavaScript compilers do not support
• A WebAssembly-based Java Virtual Machine with multi-tiered execution

Runtime

• The OpenJDK class library itself, not a reimplementation
• UI toolkits: Swing and AWT, with an integrated window manager
• System integration, including the clipboard, file systems, networking and sockets, audio and printing
• Threads, garbage collection and class loading handled by the runtime

Application types

• Standalone Java applications
• Java Applets
• Java Web Start / JNLP
• Oracle Forms and Oracle EBS applications

Why are CheerpJ extensions limited to Java 8?

Java 8 is the last long-term support release to include the Java plug-in and Java Web Start, so the applets and JNLP applications the extensions run were built for it. Keeping the extensions on Java 8 alone also keeps their package minimal in size.

Language and bytecode

• 100% of the Java language and bytecode
• Reflection, proxy classes and dynamic constructs
• Custom class loaders
• Encrypted and obfuscated bytecode

Application packaging

• JAR files
• Java Applets
• Java Web Start

Networking and files

• HTTP and HTTPS
• TCP and UDP through Tailscale or a custom networking backend
• Browser-based and network-based virtual file systems
• Local files through browser uploads and downloads

Desktop features

• Clipboard, internal or shared with the system clipboard
• Printing
• Audio

Back-end services (HTTP)

A Java application running with CheerpJ keeps using its existing APIs and back-end services. Its requests are made from the user’s browser, so the browser’s security model and your network configuration apply. Services on a different domain from the page need to allow cross-origin requests from it.

Back-end services (TCP/UDP)

Browsers do not give web pages TCP or UDP connections. CheerpJ provides them through Tailscale, a VPN based on WireGuard that carries the traffic over WebSockets, and the Tailscale control server can be self-hosted on your own network.

Enterprise deployments can also connect a custom networking backend, for example to go through their own proxies or to use other transports such as WebSockets.

Authentication

When CheerpJ is self-hosted, the page that starts the application can sit behind your existing authentication, so users sign in through your normal access controls before it loads.

The runtime is delivered over HTTPS, and the application’s HTTP requests are made with the browser’s fetch, so both inherit the browser’s certificate handling: your organisation’s root certificates, client certificates and TLS policies apply, with no Java keystore to configure.

Hosting

CheerpJ Core and the CheerpJ extensions can be self-hosted, and in enterprise deployments they normally are. Both are static files, served from your own web server or CDN, so a deployment can be completely air-gapped, with no connection to any external network.

The server needs to support HTTP range requests, and production deployments should use HTTPS, with MIME types and caching configured where required.

System-level integration

Direct process execution, local system services and OS-level hooks require adjustment.

Direct file access

Integration with the local file system through uploads and downloads works, but the browser sandbox prevents direct file access, so some workflows need re-architecting.

Direct hardware access

USB devices, serial ports, smart cards and proprietary hardware require web-compatible APIs.

JNI and native dependencies

Custom native libraries (DLLs and SOs) need to be replaced with a browser-compatible build.

Low-level networking

Non-HTTP protocols and raw sockets need a Tailscale network or another custom networking implementation.