Anzeichen, dass es Zeit wird

Die Anwendung läuft noch auf Java 8 oder 11, und ein neueres JDK bricht den Build.
Sie hängt an Spring Boot 2, Karaf/OSGi oder einem Applikationsserver, den niemand anfassen will.
Sicherheitsscanner melden Bibliotheken, die sich nicht aktualisieren lassen, ohne alles andere mitzuziehen.
Neue Entwickler brauchen Tage, bis das Projekt lokal läuft.

Was sich meist ändern muss

JAXB, JAX-WS und andere aus dem JDK entfernte Module kommen als explizite Abhängigkeiten zurück.
Der Namensraum javax.* wird für Spring Boot 3 und aktuelles Jakarta EE zu jakarta.*.
Build-Plugins, Testbibliotheken und Bytecode-Werkzeuge brauchen Versionen, die Java 21 verstehen.
Code und Bibliotheken, die per Reflection auf JDK-Interna zugreifen, müssen ersetzt oder explizit freigegeben werden.

So gehe ich vor

Zuerst die Bestandsaufnahme. Ich erfasse Module, Abhängigkeiten und Annahmen über die Laufzeit und halte fest, welche Teile Tests haben und welche nicht.
Ein reproduzierbarer Build. Vor jedem Upgrade muss das Projekt auf jedem Rechner und in der Pipeline gleich gebaut werden und laufen.
Upgrade in Etappen. Abhängigkeiten, Frameworks und JDK wechseln in auslieferbaren Schritten statt in einem langen Branch, der nie gemergt wird.
Tests dort, wo das Risiko liegt. Ich ergänze Tests um den Code, den das Upgrade am stärksten berührt, statt einer Abdeckungszahl hinterherzulaufen.
Die Weiterentwicklung läuft weiter. Neue Funktionen und Fehlerbehebungen gehen während der Migration weiter. Bei SIB-BW2 laufen beide parallel.

Aktuelles Projekt: SIB-BW2

SIB-BW2 verwaltet Straßeninfrastruktur für eine deutsche Landesverwaltung. Ich arbeite an der Umstellung von Java 8/Karaf auf Java 21/Spring Boot, habe rund 30 Berichte umgesetzt und das Migrationstool entwickelt, das bei Bedarf Tausende Bauwerke in den ASB-ING-Standard überführt.

Was Sie erhalten

Eine schriftliche Bestandsaufnahme von Laufzeit, Abhängigkeiten und Risiken, mit einer Upgrade-Reihenfolge
Die aktualisierte Anwendung, in Etappen ausgeliefert
Tests um den Code, den das Upgrade verändert hat
Eine Dokumentation der Änderungen und wie die Anwendung gebaut, betrieben und ausgeliefert wird

Wann ich davon abrate

Die Anwendung wird ohnehin innerhalb eines Jahres ersetzt.
Sie ist so klein, dass ein Neubau auf aktuellem Stack weniger kostet als das Upgrade.

Fragen zum Java-Upgrade

Müssen wir erst über Java 11 und 17 gehen?

Nicht unbedingt. Das JDK kann oft direkt auf 21 wechseln, aber Bibliotheken und Frameworks ziehen meist in Etappen um, weil jede eigene inkompatible Änderungen mitbringt. Die Reihenfolge ergibt sich aus der Bestandsaufnahme.

Brauchen wir Spring Boot 3?

Wenn die Anwendung Spring Boot 2 nutzt, früher oder später ja: Version 2 erhält keine Open-Source-Updates mehr. Spring Boot 3 setzt Java 17 oder neuer und den Namensraum jakarta.* voraus und gehört deshalb meist zum selben Projekt.

Kann das System während der Migration weiterlaufen?

Ja. Genau dafür wird in Etappen umgestellt. Jede Etappe wird ausgeliefert und geprüft, bevor die nächste beginnt.

Was ist mit Anwendungen auf Karaf/OSGi oder einem Applikationsserver?

Sie brauchen einen zusätzlichen Schritt: den Wechsel auf eine Laufzeit, die aktuelle Frameworks unterstützen, meist Spring Boot mit eingebettetem Server. Genau diesen Wechsel mache ich bei SIB-BW2.

Lohnt es sich, Ihren Prozess oder Ihre Software genauer anzusehen?

Ein kurzes Gespräch reicht, um zu klären, ob ein Audit, eine kleine Umsetzung oder bewusst keine Individualsoftware der richtige nächste Schritt ist.

Problem beschreiben