GlassFish-Hotswap in Sekunden: So beschleunigen Sie Java-Redeploys um 95 %

Seit Jahren kämpfen Java-Entwickler mit einem frustrierenden Paradox: Während die Technologie fortschreitet, bleibt das Daily Business oft in althergebrachten Workflows stecken. Ein besonders zeitfressendes Beispiel ist der Redeploy in GlassFish, der bei Jakarta-EE-Projekten regelmäßig Minuten in Anspruch nimmt – selbst wenn nur eine einzelne Methode angepasst wurde.

Doch was, wenn diese Wartezeit der Vergangenheit angehören könnte? Ein neues Open-Source-Tool namens gf beweist: Mit den richtigen Werkzeugen lässt sich der Redeploy-Prozess radikal beschleunigen. Statt zwei Minuten dauert der Hot-Swap nun nur noch drei bis sechs Sekunden. Und das Beste: Es funktioniert direkt aus der Konsole – ganz ohne teure Lizenzen oder IDE-Abhängigkeiten.

Warum Redeploys in GlassFish so lange dauern

Die typische Java-Entwicklungsroutine sieht oft so aus:

• Eine Zeile Code wird geändert.
• Die Datei wird gespeichert.
• Das WAR-Archiv wird neu kompiliert.
• GlassFish deinstalliert die Anwendung, installiert sie neu und startet alle Komponenten neu – inklusive CDI, EJBs, JPA und JSF.
• Erst dann kann der Browser aktualisiert werden.

Bei einem durchschnittlichen Projekt summieren sich diese Schritte schnell auf zwei Minuten pro Redeploy. Bei 40 Änderungen am Tag sind das über eine Stunde verlorene Zeit – Zeit, die eigentlich in die Codequalität oder Fehlerbehebung fließen sollte.

Doch die Ironie: Die meisten dieser Änderungen erfordern gar keinen vollständigen Redeploy. Eine angepasste Methode, eine korrigierte Bedingung oder ein neuer Rückgabewert könnten theoretisch sofort wirksam werden. Die JVM selbst unterstützt Hot-Swapping bereits seit Java 5. Das Problem lag nicht in der Technologie, sondern in der Zugänglichkeit.

"Die JVM kann Klassen seit fast zwei Jahrzehnten hot-swappen. Das fehlende Glied war nicht die Fähigkeit, sondern der Zugang dazu."

Die üblichen Lösungen und ihre Grenzen

Vor der Entwicklung von gf wurden verschiedene Ansätze getestet – jeder mit eigenen Einschränkungen:

IntelliJ Ultimate

Die Hot-Swap-Integration von IntelliJ Ultimate funktioniert zuverlässig, ist jedoch an die IDE gebunden. Das passt nicht zu jedem Workflow:

• Manche Entwickler nutzen IntelliJ Community oder VS Code.
• Andere arbeiten in Terminals mit externen Tools wie Claude Code.
• CI-Pipelines oder Remote-Sessions erfordern eine terminalbasierte Lösung.

Der Wunsch nach einem plattformunabhängigen Ansatz blieb bestehen.

JRebel

JRebel ist eine der ausgereiftesten Lösungen für Hot-Swapping und unterstützt sogar strukturelle Änderungen wie neue Methoden oder Felder. Allerdings:

• Die Lizenzkosten sind für kleine Teams oder Einzelentwickler oft eine Hürde.
• Die Einrichtung erfordert zusätzliche Konfiguration.
• Nicht alle Unternehmensumgebungen erlauben die Integration.

Für ein sofort einsatzbereites Tool war JRebel daher keine Option.

DCEVM

Die Dynamic Code Evolution Virtual Machine geht noch einen Schritt weiter, indem sie nicht nur Methoden, sondern auch Klassenstrukturen anpassen kann. Doch die Vorteile bringen Herausforderungen mit sich:

• Es wird eine angepasste JVM benötigt.
• Neuere Java-Versionen werden oft erst später unterstützt.
• In vielen Unternehmen ist der Austausch der Standard-JVM untersagt.

Für die meisten Entwickler war der Aufwand zu hoch für den erzielbaren Nutzen.

Die Lösung: Ein terminalbasierter Hot-Swap mit JDWP

Der Durchbruch gelang durch die Nutzung des Java Debug Wire Protocol (JDWP), das bereits in jeder JVM enthalten ist. Statt auf IDE-Features oder kommerzielle Tools zu setzen, wurde eine einfache Kommandozeilen-Schnittstelle geschaffen, die direkt mit der Laufzeitumgebung kommuniziert.

Das Ergebnis ist das Tool gf, das mit nur wenigen Befehlen auskommt:

./gf sync    # Kompiliert geänderte Java-Dateien und überträgt sie live
./gf ui      # Aktualisiert statische Ressourcen (XHTML, CSS, JS) ohne Kompilierung
./gf full    # Fällt bei strukturellen Änderungen auf traditionellen Redeploy zurück

Der Workflow ist denkbar einfach:

1. Code wird bearbeitet und gespeichert.
2. Der Befehl ./gf sync wird ausgeführt.
3. Die Änderung ist sofort in der Anwendung sichtbar – ohne Neustart oder Wartezeit.

Diese terminalbasierte Lösung bietet entscheidende Vorteile:

• Plattformunabhängig: Läuft in jedem Terminal, CI/CD-Pipeline oder Remote-System.
• Einfach zu integrieren: Kann in Makefiles, Skripte oder sogar KI-gestützte Entwicklungstools eingebunden werden.
• Keine zusätzlichen Kosten: Funktioniert mit Standard-JVM und Open-Source-Code.

Wie JDWP Hot-Swapping technisch funktioniert

Hinter den Kulissen nutzt gf eine wenig bekannte, aber mächtige Funktion der JVM: das Redefinieren von Klassen über JDWP. Dieser Mechanismus wird normalerweise für Debugging-Zwecke genutzt, lässt sich aber auch für Hot-Swapping verwenden.

Die technische Umsetzung ist denkbar simpel:

1. JVM mit JDWP starten:

glassfish/bin/startserv

as mit aktiviertem Debug-Port:

-asadmin start-domain --debug=true

1. Verbindung zur JVM herstellen und die geänderte Klasse identifizieren:

1. Neuen Bytecode einlesen und an die JVM übermitteln:

1. Klassenimplementierung ersetzen – ohne Neustart oder neuen Classloader.

Der Kern der Implementierung besteht aus nur etwa zehn Zeilen Java-Code:

VirtualMachine vm = connector.attach(arguments);
for (Path classFile : changedClassFiles) {
    String className = classFile.toClassName();
    List<ReferenceType> types = vm.classesByName(className);
    if (types.isEmpty()) continue;
    byte[] bytecode = Files.readAllBytes(classFile);
    vm.redefineClasses(Map.of(types.get(0), bytecode));
}
vm.dispose();

Ein begleitendes Bash-Skript übernimmt die umliegenden Aufgaben:

• Erkennung geänderter Dateien
• Inkrementelle Kompilierung
• Unterstützung für Lombok
• Fehlerbehandlung
• Fallback auf vollständigen Redeploy bei strukturellen Änderungen

Langfristige Vorteile jenseits der Geschwindigkeit

Die Zeitersparnis ist offensichtlich – doch der größte Gewinn liegt woanders: Die Konzentration auf die eigentliche Arbeit.

Statt zwischen Code-Änderungen und Deployment-Logs hin- und herzuspringen, bleibt der Fokus auf der Logik. Fehler werden schneller erkannt, Feedbackzyklen verkürzen sich, und selbst CI/CD-Pipelines profitieren von der Möglichkeit, Hot-Swaps in Build-Prozesse zu integrieren.

Und das Beste: gf ist nicht auf GlassFish beschränkt. Die Technologie lässt sich auf andere Jakarta-EE- oder Spring-Boot-Anwendungen übertragen – solange die JVM JDWP unterstützt.

Die Zukunft des Java-Entwicklungs-Workflows könnte einfacher sein, als viele denken. Es braucht keine revolutionären Tools – manchmal reicht ein kleines Skript, das die vorhandenen Möglichkeiten der JVM nutzt. Der nächste Schritt? Vielleicht eine Integration in gängige Build-Tools oder eine offizielle Unterstützung durch Application Server.

Eines ist sicher: Die Tage der zweiminütigen Redeploy-Wartezeit sind gezählt.