Von Java EE zu Jakarta EE 11

Von Java EE zu Jakarta EE 11

0:00 Dieses Modul behandelt den Schritt, der in fast jedem Modernisierungsprojekt vorkommt — unabhängig davon, ob am Ende ein Application Server oder Quarkus steht. Der Weg von Java EE zu Jakarta EE 11 klingt zunächst nach einer Umbenennung, und in Teilen ist er das auch. Aber mittendrin liegt ein Wechsel, der jede einzelne Datei der Anwendung berührt: der Wechsel des Package-Namensraums von javax auf jakarta.

0:23 Wir sehen uns an, welche Stationen auf diesem Weg liegen, was Jakarta EE 11 an Neuem mitbringt, wie sich der Namensraumwechsel automatisieren lässt — und warum die Java-Version dabei besser ein eigener Schritt bleibt.

Von Java EE zu Jakarta EE 11

0:36 Wir sind weiter im Analyseteil, aber dieses Modul hat zum ersten Mal einen praktischen Anteil: Sie stoßen einen automatisierten Umbau an und sehen, was er leistet — und wo er aufhört. Genau diese Grenze ist die wichtigste Erkenntnis des Moduls, denn sie bestimmt, wie viel Handarbeit im Rest der Anwendung steckt.

Der Weg von Java EE 7 zu Jakarta EE 11

0:54 Sehen wir uns zuerst die Landkarte an. Vier Stationen liegen zwischen Java EE 8 und Jakarta EE 11 — und nur eine davon tut wirklich weh. Wenn Sie wissen, welche das ist, können Sie den Aufwand Ihres eigenen Sprungs ziemlich genau einschätzen — noch bevor Sie eine einzige Zeile anfassen. Jakarta EE 11 ist die aktuelle Plattformversion, seit Juni 2025 verfügbar und unter anderem für Open Liberty, WildFly und Payara Server zertifiziert.

1:21 Zwei Zahlen sind für die Planung wichtig. Erstens: Java 17 ist das Minimum — wer heute auf Java 8 oder 11 steht, hat also zwei Aufgaben vor sich, nicht eine. Zweitens: Für Java 21 und neuer gibt es zusätzliche Möglichkeiten, insbesondere rund um Virtual Threads. Der Zeitpunkt ist übrigens günstig: Mit drei zertifizierten Servern haben Sie bei der Zielwahl echte Auswahl, nicht nur einen Anbieter.

1:48 Diese Kette zeigt, warum die Frage „von wo nach wo" wichtiger ist als die Frage „wohin". Der Sprung von Java EE 8 auf Jakarta EE 8 ist praktisch kostenlos — dieselbe Technik, ein neuer Name, eine neue Stiftung dahinter. Der Sprung auf Jakarta EE 9 ist der teure, weil dort der Namensraum wechselt. Und alles danach ist wieder normale Versionspflege.

2:09 Wenn Sie also heute auf Java EE 8 stehen, liegt Ihre gesamte Migrationsarbeit in genau einem dieser vier Schritte. Das ist eine gute Nachricht: Sie können ihn isolieren, planen und einzeln absichern. Die Logik dieser Tabelle ist eine Aufwandsverteilung — und sie ist erstaunlich unausgewogen. Drei Stationen kosten wenig bis mittel, eine kostet viel.

2:32 Daraus folgt eine sehr praktische Empfehlung: Planen Sie nicht den Sprung von Java EE 8 auf Jakarta EE 11 als ein Vorhaben. Planen Sie ihn als zwei. Erst nach Jakarta EE 9, mit vollständigem Test und produktiver Auslieferung. Dann, in Ruhe, weiter auf 10 und 11. Der Grund ist banal, aber wirksam: Wenn nach einem Schritt etwas kaputt ist, wissen Sie, welcher Schritt es war.

2:57 Vier Neuerungen, und die erste ist die interessanteste für gewachsene Anwendungen. Jakarta Data standardisiert das Repository-Muster — also genau die Schicht, die in vielen Bestandsanwendungen selbst gebaut wurde, in jedem Projekt ein bisschen anders. Jakarta Persistence bildet inzwischen java.time-Typen direkt ab; wer noch mit Date und Calendar arbeitet, hat hier einen naheliegenden Aufräumpunkt.

3:19 Und Virtual Threads in der Concurrency-Spezifikation sind für Migrationen besonders attraktiv, weil sie blockierenden Code entlasten, ohne dass man ihn auf ein reaktives Modell umschreiben muss. Ein Gewinn, der ohne Architekturbruch zu haben ist. Die letzten drei Punkte sind konkrete Fallen, die Sie im Zweifel Tage kosten.

3:39 Managed Beans wurden entfernt — an ihre Stelle tritt CDI, und das ist meist wenig Arbeit, muss aber gefunden werden. Deutlich unangenehmer: Jakarta XML Binding und SOAP with Attachments sind nicht mehr Teil der Plattform. Wenn Ihre Anwendung Webservices im klassischen Sinn betreibt, ist das kein Detail, sondern ein eigenes Arbeitspaket.

3:59 Und in Jakarta REST 4.0 ist die Context-Annotation abgekündigt — noch funktionsfähig, aber ein Kandidat für den nächsten Sprung. Prüfen Sie diese drei Punkte, bevor Sie den Zeitplan aufstellen.

Der Namensraumwechsel

4:11 Jetzt zum Herzstück. Der Namensraumwechsel gilt als Suchen-und-Ersetzen-Aufgabe — bis man merkt, wie viele der betroffenen Stellen gar keine Java-Datei sind. Wir sehen uns an, was Werkzeuge zuverlässig erledigen und welche Sorten von Fundstellen dabei regelmäßig übrig bleiben. Ab Jakarta EE 9 heißen die Pakete jakarta statt javax. Das klingt nach einer Aufgabe für den Editor, und für die Imports ist es das auch.

4:37 Aber betroffen sind ebenso Deployment-Deskriptoren, Konfigurationsdateien mit eigenem Schema, per Reflection geladene Klassennamen, generierter Code und die Tests. Stellen Sie es sich vor wie eine Straßenumbenennung: Die Schilder sind schnell getauscht. Aber die Adresse steht auch auf Briefköpfen, in Verträgen und in fremden Datenbanken.

4:57 Werkzeuge nehmen den größten Teil ab. Den Rest findet nur ein Lauf gegen echte Tests. Worauf es hier ankommt, ist nicht der erste Aufruf, sondern die beiden letzten. Das OpenRewrite-Rezept macht die eigentliche Umbenennung, zuverlässig und in wenigen Minuten. Aber die entscheidende Information liefert der Blick danach: Was hat sich geändert, und was ist übrig geblieben? Deshalb der Diff und deshalb die gezielte Suche in den XML-Dateien.

5:23 Genau dort greifen die Rezepte am wenigsten, weil Konfigurationsdateien eigene Schemata haben. Ein Rat aus der Praxis: Lassen Sie den Lauf nur auf einem sauber eingecheckten Stand los. Sonst können Sie hinterher nicht mehr unterscheiden, was das Werkzeug geändert hat und was Sie selbst. Diese vier Punkte sind die Handarbeit, die nach dem Werkzeuglauf übrig bleibt. Der erste und der letzte sind die gefährlichsten, weil sie in entgegengesetzte Richtungen gehen.

5:51 Klassennamen in Zeichenketten werden zu selten ersetzt — sie stehen in Konfigurationen oder in Reflection-Aufrufen und fallen erst zur Laufzeit auf. Umgekehrt gibt es Pakete mit javax-Präfix, die zur Java-Plattform selbst gehören, etwa javax.sql oder javax.naming. Die dürfen auf keinen Fall umbenannt werden. Ein zu eifriges Suchen-und-Ersetzen ist hier schädlicher als ein zu vorsichtiges.

6:16 Der letzte Punkt verdient Aufmerksamkeit, weil er so leise scheitert: Die Tests werden mitmigriert und prüfen danach nichts mehr. Das passiert, wenn ein Test Mocks gegen die alten Typen baute und das Rezept beides sauber umbenennt — der Test wird grün, aber er prüft eine andere Anwendung als vorher. Prüfen Sie deshalb nach dem Lauf mindestens stichprobenhaft, ob Ihre Tests noch das Gleiche behaupten.

6:39 Und Punkt drei ist der klassische Projektstopper: eine Bibliothek ohne Jakarta-Variante. Die finden Sie am besten jetzt, in Modul drei, und nicht im Sprint vor der Abnahme.

Java-Version und Laufzeit

6:49 Bleibt der zweite Wechsel, der oft im selben Atemzug genannt wird — und der genau deshalb Ärger macht. Die Java-Version zu heben ist eine eigene Aufgabe mit eigenen Risiken. Warum sie trotzdem nicht in denselben Schritt gehört, ist das Thema dieses Kapitels. Jakarta EE 11 verlangt mindestens Java 17. Damit steht für viele Bestandsanwendungen ein zweiter Wechsel an, und der hat ganz eigene Risiken: das Modulsystem, entfernte APIs, geänderte Zeitzonendaten, strengere Zugriffsprüfungen auf interne Klassen.

7:20 Nichts davon hat mit Jakarta EE zu tun. Und genau deshalb gehört es nicht in denselben Schritt. Wer beides gleichzeitig macht, hat bei jedem Fehler zwei mögliche Ursachen und keine Möglichkeit, sie zu trennen. Zwei aufeinanderfolgende Schritte dauern zusammen kürzer als ein gemeinsamer, bei dem man die Fehlersuche zweimal macht.

7:40 Diese Gegenüberstellung zeigt, warum die Reihenfolge so klar ist. Der Java-Wechsel betrifft Laufzeit und Werkzeuge und erzeugt wenige, dafür tiefe Fehlerbilder — etwas startet nicht, eine Bibliothek verweigert den Dienst. Der Namensraumwechsel betrifft jede Quelldatei und erzeugt viele, dafür flache Fehler: Import nicht gefunden, hundertfach. Beide Fehlerarten sucht man völlig unterschiedlich.

8:03 Und die Rückwege sind verschieden: Beim Java-Wechsel stellen Sie die JDK-Wahl zurück, beim Namensraum nehmen Sie den Stand aus der Versionsverwaltung. Erst Java, dann der Namensraum — in dieser Reihenfolge bleibt beides beherrschbar. Der erste Punkt ist für Migrationsprojekte der interessanteste. Virtual Threads entlasten blockierende Verarbeitung, ohne dass Sie Code auf ein reaktives Modell umschreiben müssen.

8:28 Und genau das ist bei gewachsenen Anwendungen Gold wert: Die klassische Enterprise-Anwendung ist blockierend geschrieben, von der Datenbankabfrage bis zum Webservice-Aufruf. Ein Umbau auf reaktive Programmierung wäre ein eigenes, riskantes Projekt. Virtual Threads bieten hier einen Gewinn ohne Architekturbruch — vorausgesetzt, der Code kommt ohne die alten Synchronisationsmuster aus.

8:50 Wo das nicht der Fall ist, verschiebt sich das Problem nur. Der dritte Punkt ist einer, an den beim Java-Wechsel fast niemand denkt: Die Zeitzonendaten in der Java-Laufzeit werden mit jeder Version aktualisiert. Für die meisten Anwendungen ist das folgenlos. Für eine Anwendung wie Zählwerk, in der Ablesezeitpunkte über Abrechnungsgrenzen entscheiden, kann eine geänderte historische Zeitzonenregel Werte verschieben.

9:14 Prüfen Sie das gezielt, wenn Sie mit Zeitstempeln rechnen. Und der letzte Punkt ist die Zusammenfassung dieses ganzen Kapitels: Wenn Java-Wechsel und Namensraumwechsel gemeinsam laufen, wird die Fehlersuche unmöglich — nicht schwierig, unmöglich.

Übung

9:28 Zeit für die Praxis. Sie stoßen den Wechsel an einem Modul von Zählwerk an — und das eigentliche Ergebnis wird nicht der grüne Build sein. Das Ergebnis ist die Liste dessen, was Sie von Hand nachziehen mussten — und die schätzt den Aufwand für den gesamten Rest der Anwendung. Sie stellen ein Modul von Zählwerk auf den jakarta-Namensraum um.

9:48 Das Lernziel ist zweigeteilt: Sie führen einen Namensraumwechsel automatisiert durch — das ist der einfache Teil — und Sie erkennen die Stellen, die kein Werkzeug abdeckt. Der zweite Teil ist der wertvolle. Erfolgreich sind Sie, wenn das Modul gegen Jakarta EE 11 baut und jede von Hand nachgezogene Stelle mit Begründung in einer Liste steht.

10:07 Und beachten Sie die Reihenfolge: erst die Java-Version heben, den Stand sichern, und danach den Namensraum wechseln. Genau in dieser Trennung liegt der Lerneffekt. Der rote Faden ist Messbarkeit. Schritt eins erhebt die Grundlinie — wie viele Dateien nennen heute javax? Diese Zahl brauchen Sie am Ende zum Vergleich, und sie kostet zehn Sekunden.

10:28 Schritt zwei und drei trennen die beiden Wechsel sauber voneinander, mit einem gesicherten Stand dazwischen. Schritt vier ist die Handarbeit, und Schritt fünf benennt die Bibliothek, die den Wechsel blockiert. Diese Liste der Handarbeit ist das eigentliche Ergebnis: Sie ist die Grundlage, um den Aufwand für den Rest der Anwendung hochzurechnen — belastbar, weil gemessen statt geschätzt.

10:50 Der erste Punkt ist der, der Ihnen die Übung ruinieren kann: ein Lauf ohne gesicherten Stand. Danach lässt sich nicht mehr trennen, was das Werkzeug getan hat und was Sie. Ein Commit vorher kostet nichts. Und der dritte Punkt ist der stille: Die Tests laufen grün, weil sie mitgeändert wurden. Grün ist in diesem Modul kein Beweis, sondern eine Frage — nämlich: Prüfen diese Tests überhaupt noch dasselbe?

11:15 Wie man Verhalten so festschreibt, dass es einen Umbau überlebt, sehen wir uns in Modul dreizehn genauer an.