CheerpJ 5.0 bringt Java 21 und 25 samt vollständigem OpenJDK in den Browser

Serverraum mit langen Reihen von Racks, Glasfaserverkabelung und kuehlen blauen Kontrollleuchten
Deine Reaktion:

CheerpJ 5.0 unterstützt Java 25. Damit deckt die OpenJDK-Distribution für den Browser die aktuellen Java-Releases ab, nach Java 8, 11 und 17. Java war bisher vor allem auf Servern und Desktops zu Hause; der Browser kommt als dritte Plattform hinzu. Interessanter als die Versionsnummer ist ein zweiter Ausführungsmotor, den das Projekt noch als experimentell kennzeichnet.

Der Vergleich mit einem Dolmetscher hilft: Der Browser kennt nur JavaScript und WebAssembly, Java-Bytecode nicht. CheerpJ übersetzt laufend, was die Anwendung ausführt. Es arbeitet nicht mit Quelltext, sondern mit Bytecode. Darum laufen auch obfuskierte JARs, alte Firmware ohne Quellcode und alles, wofür es längst keinen Quelltext mehr gibt.

Ein Dolmetscher für Bytecode: Aufbau von CheerpJ 5.0

CheerpJ gibt es seit 2017. Es war von Anfang an als vollständige JVM in WebAssembly angelegt, nicht als Sammlung von Hilfskonstruktionen für einzelne Bibliotheken. Die heutige Architektur stammt von CheerpJ 3.0 aus dem Jahr 2024: ein JIT-Compiler, der selbst nach WebAssembly kompiliert wird. Das entfernte Vorverarbeitungsschritte und verbesserte die Kompatibilität mit gewachsenem Code. Seitdem besteht das System aus drei Teilen.

Der erste Teil ist die JVM mit JIT-Compiler, in C++ geschrieben und nach WebAssembly übersetzt. Code startet im Interpreter; heißer Code wird kompiliert, mit Optimierungen wie Inlining und Devirtualisierung. Der zweite Teil ist ein unveränderter OpenJDK-Build für jede unterstützte Java-Version, samt JNI-Schicht, ebenfalls nach WebAssembly übersetzt. Der dritte Teil ist eine virtualisierte Systemschicht: mehrere Dateisysteme, Assets über HTTP, persistenter Speicher in IndexedDB, Daten aus JavaScript, Netzwerk über Tailscale, Zwischenablage und ein Fenstermanager für mehrere Java-Fenster auf einer Seite.

Weil alles auf Bytecode-Ebene arbeitet, funktionieren Reflection, Klassengenerierung zur Laufzeit, eigene ClassLoader, Multithreading und Synchronisation. Das unterscheidet CheerpJ von Lösungen, die nur für den Browser umgeschriebenen Java-Code verarbeiten. Und weil die JVM Bytecode liest, laufen Kotlin und Scala ohne Zusatzarbeit. Für den Bytecode ist egal, in welcher Sprache der Code vorher geschrieben wurde.

Java 21 und Java 25 im Browser – mit vollständigem JDK

Bisher lieferte CheerpJ nur die JRE-Pakete von OpenJDK aus, um Downloadgröße und Startzeit klein zu halten. Nach Optimierungen an der I/O-Logik kann das Projekt nun das vollständige JDK für jede unterstützte Version mitliefern. Das ändert mehr als nur die Downloadgröße: Java lässt sich im Browser damit nicht nur ausführen, sondern auch kompilieren. javac und jshell laufen clientseitig, ohne Server.

Damit ist eine Roadmap von Februar 2025 erfüllt. Sie nannte als Ziel, bis Ende 2026 Parität mit dem neuesten Java-LTS zu erreichen. Mit Java 21 und 25 ist das vor dem ursprünglichen Termin erreicht. Wer Java bisher als Werkzeug für Altlasten kannte, ändert die Einordnung: CheerpJ ist eine alternative JVM mit vollständiger OpenJDK-Laufzeit, deren Plattform der Browser ist. Der Ausbildungssektor dürfte zuerst profitieren, weil sich Programmierumgebungen ohne Installation und ohne Rechnerflotte bereitstellen lassen.

Die WasmGC-Engine: Java-Objekte werden zu WebAssembly-Objekten

Der größte Umbau seit der JIT-Architektur betrifft nicht die Java-Version, sondern den Motor darunter. CheerpJ 5.0 enthält eine experimentelle Alternative zur bisherigen Engine: einen schnelleren Interpreter und ein zweites JIT-Backend, das auf WebAssembly GC aufsetzt. In der Standard-Engine sind Java-Objekte JavaScript-Objekte, und heißer Code wird zu JavaScript kompiliert. In der WasmGC-Engine werden Java-Objekte zu WasmGC-Objekten, und heißer Code wird zu WebAssembly kompiliert. Der Speicher bleibt in beiden Fällen unter Kontrolle des Garbage Collectors des Browsers.

Die Erwartung: bessere Startzeiten und bessere Laufzeit als mit der stabilen Engine. WasmGC vereinfacht außerdem die Interaktion mit komplexen nativen Bibliotheken, die selbst nach Wasm kompiliert sind, etwa LWJGL, ein Baustein für Minecraft und viele andere Java-Spiele. LWJGL 2 wird bereits unterstützt. LWJGL 3 lief bisher nur mit hohem Performance-Overhead und war praktisch unbrauchbar. Die neue Engine soll das Problem umgehen.

Der Haken ist der Reifegrad. Die WasmGC-Engine ist ausdrücklich experimentell, instabil und muss per cheerpjInit({ wasmGC: true }) aktiviert werden. Sie verlangt aktuelle Browser: Chrome und Edge ab Version 137, Firefox ab 153, Safari ab 27, mobil iOS und iPadOS 27. Einen automatischen Rückfall auf die Standard-Engine gibt es noch nicht; für den produktiven Einsatz ist sie deshalb nicht geeignet. Der Hersteller nennt CheerpJ 6.0 als Zielmarke für eine stabile WasmGC-Engine, geplant für Anfang 2027.

Was heute im Browser läuft

Konkreter als die Ankündigungen ist das, was mit der stabilen Engine bereits läuft. Swing- und AWT-Anwendungen werden unterstützt, einschließlich eigener Look-and-Feel-Implementierungen, mehrerer Fenster, Zwischenablage und Druckfunktion. Meist rendert eine Anwendung genauso wie unter einer Desktop-JVM. Die Demo der Bibliothek FlatLaf läuft live im Browser.

Der bekannteste Test ist Browsercraft, eine Web-Einbettung einer historischen Java-Version von Minecraft. Anders als bei vielen ähnlichen Projekten basiert das nicht auf Dekompilierung oder Reverse Engineering: Die originale client.jar wird direkt von Mojang-Servern geladen und läuft unverändert im Browser. Der Autor des Beitrags nennt Minecraft einen kritischen Benchmark und erwartet, dass moderne Versionen inklusive Mods mit Java 21 und 25 sowie einer stabilen WasmGC-Engine praktisch lauffähig werden.

Der Library Mode erlaubt es, Java-Bibliotheken aus JavaScript mit async/await anzusprechen, inklusive direktem Zugriff auf Methoden, Objekte und Arrays. Native Methoden lassen sich in JavaScript implementieren, ähnlich wie JNI auf klassischen Plattformen. Ein Beispiel: die iText-Bibliothek erzeugt ein PDF vollständig clientseitig, ohne Server. Eine Integration in BrowserCode, eine einbettbare browserbasierte IDE, zeigt außerdem, wie sich Code ändern und direkt ausführen lässt.

Wo die Grenzen liegen – und was bis CheerpJ 6.0 fehlt

JavaFX und SWT werden nicht unterstützt, sind aber in der Pipeline. Bei konkreten Abhängigkeiten bietet der Hersteller frühe Vorschauen an. Offen bleibt auch die Performance für große Anwendungen, denn die Ankündigung schnellerer Laufzeiten bezieht sich überwiegend auf die noch nicht stabile WasmGC-Engine. Wer heute plant, sollte mit der Standard-Engine kalkulieren und die neue Variante als Testfeld behandeln, nicht als Zusage.

Neben den großen Neuerungen nennt der Beitrag viele kleine, wirksame Verbesserungen. Java 11 und 17 gelten nach Tests aus der Community und von Kunden als stabil genug für die meisten Anwendungen ohne Zusatzarbeit. Das Parsen von Klassendateien wurde beschleunigt, die JIT-Engine neu abgestimmt, der Download von JARs optimiert. Auch Drag and Drop, Zwischenablage und Mobilität wurden verbessert. Mobilität begann mit CheerpJ 4.3 und wird weitergeführt.

Was das für Java als Plattform bedeutet

Pragmatisch gelesen ist dieses Release wenig spektakulär und trotzdem wichtig. Java hat mit dem Browser eine dritte Laufzeitumgebung, die keine Portierung verlangt, sondern Bytecode akzeptiert, wie er ist. Firmen, die seit Jahren Oracle Forms oder E-Business-Suite-Installationen am Leben halten, sind kein Randfall; für sie existiert das Projekt überhaupt. Dass nun ein vollständiges JDK mit javac und jshell im Browser sitzt, öffnet dieselbe Technik für Lehre, Prototyping und Werkzeuge, die bisher einen Server im Hintergrund brauchten.

Der realistische Blick bleibt nötig. Die WasmGC-Engine ist eine Ankündigung mit Datum, kein Produktversprechen. Die genannten Mindestversionen der Browser schränken den Adressatenkreis ein. Ob moderne Minecraft-Versionen mit Mods flüssig laufen, entscheidet nicht der Blogbeitrag, sondern der Benchmark. Wer heute auf CheerpJ setzt, sollte die stabile Engine nehmen, die experimentelle Variante testen und den Produktivbetrieb bis 2027 vertagen. Der Beitrag selbst ist ein Zwischenstand. Die Entwicklung läuft seit 2017 in dieselbe Richtung. Interessant ist inzwischen weniger die Versionsnummer als der Motor darunter.

Quelle: labs.leaningtech.com

Deine Reaktion:
Artikel teilen:
Krötzsch-Check0 — 100
Fakten 80
Relevanz 30
Hype 30
Einschätzung 75
Redaktion 50 Stand 50 · noch keine Stimmen
Ist das Hype?
Sebastian Krötzsch
Autor

Sebastian Krötzsch

Sebastian Krötzsch schreibt auf sebask.de über Künstliche Intelligenz, Automatisierung, digitale Systeme und die Frage, was davon im Alltag wirklich nützlich ist. Ohne Buzzword-Nebel, dafür mit klarem Blick auf Praxis, Tools und echte Wirkung.