CheerpJ works directly with existing Java bytecode and application resources. The runtime, JARs and supporting files are served to the browser using standard web technologies, so a Java application can be deployed with the same servers and CDNs you already use for websites. This page explains what that involves.

How a CheerpJ deployment works

A CheerpJ deployment works in the same way as any other web application. The application’s files are hosted centrally, the browser downloads them when a user opens the page, and the Java code then runs on the user’s own device. The process has four stages:

  1. Host the assets. The CheerpJ loader and the application’s JARs, classes, libraries and resources are served from your web infrastructure.
  2. Load the runtime. A web page loads the CheerpJ runtime using JavaScript.
  3. Load the application. CheerpJ reads the existing bytecode and supporting resources directly, so nothing needs to be converted first.
  4. Execute in the browser. The Java application runs client-side, inside the browser security model. How CheerpJ works explains the runtime.

Use existing web infrastructure

Because the runtime and the application are delivered as ordinary web files, the requirements on each side are modest. The server needs to deliver the files correctly, and the user needs a modern browser.

Web server or CDN

Any web server or CDN can host a CheerpJ application, as long as it can serve HTML, JavaScript, WebAssembly, JARs and the application’s other resources. Configure MIME types, caching and cross-origin policies where your setup requires them, and use HTTPS for production deployments.

One requirement matters in particular. CheerpJ loads resources in chunks using HTTP Range Requests, so the server must support the Range header. CheerpJ cannot run from servers without it, such as Python’s http.server.

Modern browser

On the user’s side, all that is needed is a modern version of Chrome, Edge, Firefox or Safari with WebAssembly and JavaScript enabled. There is no local JVM to install and no legacy Java browser plugin. If the application uses files, the clipboard or other capabilities, the browser’s permissions for them apply.

Deploy existing Java applications

CheerpJ works directly with compiled Java bytecode. Source code access, recompilation and a frontend rewrite are not normally required, so the application you deploy is the one you already have. That covers several kinds of Java application:

  • Java applications. Existing JARs, classes, libraries, dependencies and resources are used as they are.
  • Java Applets. Supported Java 8 Applets run through a web integration or Applet Runner.
  • Java Web Start. The JARs of JNLP applications run with CheerpJ Core, or the JNLP file opens with JNLP Runner.
  • Java libraries. Java libraries can be loaded for use from JavaScript applications.

Centralised delivery to managed endpoints

The application is downloaded and executed inside the browser, rather than run through a remote desktop session, and that changes how it reaches users. Nobody needs to install or configure Java Desktop on their device, and updates are made once, by replacing the application files on the server, instead of by maintaining separate desktop installations.

It also opens up devices where installing software is difficult or not allowed. Thin clients, managed desktops and restricted endpoint environments can all reach the application through the browser.

Choose where the runtime and application assets are served

The runtime and the application files can be served from the same place or from different places, depending on how much control you need. There are three options.

Your web infrastructure

Host the application assets on your own servers, private cloud or controlled enterprise environment. This gives you control over hosting and release processes, lets you integrate with your existing authentication, and supports private or restricted deployments. Self-hosting is included with Enterprise licences, is available as an add-on with Small Business licences, and is allowed during technical evaluation.

Content delivery network

Distribute the static runtime and application assets through an enterprise CDN. You get standard web caching, geographic distribution and central management of the assets.

Leaning Technologies CDN

Use the cloud-hosted CheerpJ runtime while serving your application files from your chosen infrastructure. It is a quick way to start an evaluation, the runtime loader is versioned, and your application assets remain under your control.

Plan for browser and network constraints

A CheerpJ application runs as part of a web page, so the standard browser rules apply to it as they do to any other site. Cross-origin and content-security policies govern what the page can load and contact, browser permissions govern access to files and other capabilities, and network access goes through the browser’s APIs.

Web pages cannot open TCP and UDP connections directly, so applications that need them connect through a Tailscale network.

Request a deployment review

If your setup involves custom infrastructure, private networking, an air-gapped environment, an unusual authentication flow, a legacy delivery model or strict runtime constraints, get in touch and our engineers will review your deployment with you before you start.