Zwischen Java EE 7 und Jakarta EE 11 liegen vier Stationen, und sie sind sehr unterschiedlich teuer. Jakarta EE 8 ist bis auf den Namen identisch mit Java EE 8. Jakarta EE 10 bringt den CDI-Ausbau und das Core Profile, Jakarta EE 11 dann Jakarta Data 1.0 und Java 17 als Minimum. Dazwischen liegt Jakarta EE 9 — der einzige Sprung, der jede Datei deiner Anwendung berührt.
Ein Präfix, das überall steht
Der Wechsel von javax. auf jakarta. ist rein mechanisch, und genau deshalb
wird er unterschätzt. Werkzeuge wie OpenRewrite erledigen den Großteil in
einem Lauf. Was sie zuverlässig liegen lassen:
- Klassennamen, die als Zeichenkette im Code stehen und per Reflection aufgelöst werden
- Deskriptoren und Konfigurationsdateien mit eigenem Schema
- generierten Code, der beim nächsten Build wieder alt herauskommt
Der wichtigere Befehl nach dem Rezept ist deshalb nicht der Testlauf, sondern die Suche nach dem, was das Werkzeug nicht angefasst hat.
Nicht jedes javax ist gemeint
Hier liegt die Falle, die reihenweise Migrationen ausbremst: javax.sql und
javax.naming gehören zur Java-Plattform, nicht zu Jakarta EE. Wer ein
Rezept blind über den Quelltext laufen lässt, benennt sie mit um — und der
Fehler zeigt sich erst zur Laufzeit.
Einen Sprung nach dem anderen
Verlockend ist, den Java-Wechsel gleich mitzunehmen. Danach lässt sich nicht mehr auseinanderhalten, welcher der beiden Sprünge ein verändertes Verhalten verursacht hat. Erst der Namensraum, dann die Laufzeit.
Mehr dazu im Seminar
Wie der Lauf konkret aussieht — und wie du den Zwischenstand absicherst, bevor du weiterbaust — zeigt das Modul Von Java EE zu Jakarta EE 11 aus dem Seminar Jakarta EE modernisieren, inklusive Video und Kapitelübersicht.