Jakarta-EE-Modernisierung planen — Cheat Sheet

Der Spickzettel für die Entscheidungen vor der Migration: welcher Weg, welche Station, welches Modul zuerst. Die technische Seite — REST, CDI, Persistence, Messaging, Security, Betrieb — steht auf dem zweiten Blatt: Jakarta EE nach Quarkus migrieren. Maßgeblich sind die Jakarta-EE-Spezifikationen und die Quarkus-Dokumentation; hier stehen die Raster, die den Versionssprüngen standhalten.

Das Blatt ersetzt die Analyse nicht — es sagt, wonach zu suchen ist, nicht was dabei herauskommt.

Die fünf Modernisierungswege

Die Risiken addieren sich nicht, sie multiplizieren sich, wenn mehrere Wege gleichzeitig laufen. Gewählt wird je Anwendungsteil, nicht für die ganze Anwendung.

Vier Schritte bleiben im Bestand möglich und verlangen keine Entscheidung über die Zielplattform: Server aktualisieren (Support, Patches), Java-Version heben, containerisieren (reproduzierbare Auslieferung), Konfiguration externalisieren (gleiche Artefakte je Umgebung).

Module: Die Modernisierungsoptionen vergleichen · Gründe für die Modernisierung

Von Java EE 7 zu Jakarta EE 11

Der Sprung auf Jakarta EE 9 ist der einzige, der jede Datei der Anwendung berührt — und er reicht als eigener Schritt.

Neu in Jakarta EE 11: Jakarta Data 1.0 standardisiert Repositories über BasicRepository und CrudRepository; Persistence 3.2 bildet java.time.Instant ab und erlaubt Records als Embeddable; Concurrency 3.1 unterstützt Virtual Threads in verwalteten Ressourcen; Validation 3.1 prüft Regeln auch auf Records. Entfallen sind Managed Beans (Ersatz: CDI), Jakarta XML Binding und SOAP with Attachments; in Jakarta REST 4.0 ist @Context abgekündigt.

Modul: Von Java EE zu Jakarta EE 11

Namensraumwechsel javax → jakarta

R=org.openrewrite.java.migrate.jakarta
mvn org.openrewrite.maven:rewrite-maven-plugin:run \
  -Drewrite.activeRecipes=$R.JavaxMigrationToJakarta
git diff --stat
grep -rn "javax\." src/ --include=*.xml

Der letzte Aufruf ist der wichtigere: Er zeigt, was das Rezept nicht angefasst hat. Werkzeuge greifen regelmäßig daneben bei Klassennamen in Zeichenketten (Reflection), Deskriptoren mit eigenem Schema, generiertem Code — und bei Paketen wie javax.sql oder javax.naming, die zur Java-Plattform gehören und bleiben müssen.

Modul: Von Java EE zu Jakarta EE 11

Inventar: Fundstellen im Bestand

Die letzte Zeile ist die teuerste — sie hat in keiner Spezifikation eine Entsprechung.

grep -rl "javax\." src/main/java | wc -l
grep -rn "InitialContext\|lookup(" src/main/java
find . -name "jboss-*.xml" -o -name "weblogic-*.xml"
mvn -q dependency:tree -Dscope=provided

Was provided ist, kommt vom Server — genau dieser Teil verschwindet bei einem Wechsel und braucht danach einen Ersatz oder entfällt.

Modul: Die bestehende Anwendung inventarisieren

Reichweite von Quarkus

Diese Tabelle Zeile für Zeile gegen den eigenen Bestand zu prüfen, ist die Machbarkeitsanalyse. Im Alltag fallen die Grenzen so auf: CDI Portable Extensions gibt es nicht (Bean-Ermittlung passiert im Build), der BeanManager steht nur eingeschränkt zur Verfügung, Session-Scope hängt an einer bestimmten Erweiterung, verteilte Transaktionen über mehrere Ressourcen entfallen.

Modul: Quarkus als Modernisierungsoption

Piloten auswählen und planen

Vor dem Start stehen vier Festlegungen: Ziel (prüfbar durch einen Aufruf im Testcluster), Zeitrahmen, Akzeptanz (gleiche Antworten wie der Bestand, geprüft durch Vergleichstests) und Abbruch — beschrieben, bevor die Arbeit beginnt. Wer den Abbruch nicht vorher formuliert, verlängert im Zweifel immer.

Modul: Einen geeigneten Migrationspiloten auswählen

Ziele, Kriterien und Messpunkte

Vier Kriterien reichen. Wer zehn misst, verhandelt am Ende über die Messung statt über das Ergebnis. Der heutige Wert ist der wichtigste Teil — ohne ihn gibt es später keinen Vergleich.

Modul: Gründe für die Modernisierung

Koexistenz: was ein Migrationsschritt enthält

Ohne die letzte Zeile wächst die Anwendung, statt sich zu wandeln. Der Rückbau beweist zugleich, dass die Umleitung vollständig war.

Modul: Schrittweise Migration und Koexistenz

Analysewerkzeuge und Zielpfade

Dokumentierte Zielpfade des Migration Toolkit for Applications:

Cloud-Readiness bewertet Betriebseigenschaften, nicht APIs. Ein Werkzeugbericht ist eine Fundliste, keine Aufwandsschätzung.

quarkus update --stream=3.39
git diff --stat
./mvnw verify

Zur KI-Unterstützung liefert der 2026 veröffentlichte Benchmark ScarfBench zu Migrationen in Enterprise Java eine nüchterne Zahl: aggregierte Testpassrate 12,2 Prozent beim stärksten untersuchten Agenten, 1 von 204 Aufgaben vollständig verhaltensgleich. Das ist ein Forschungsbenchmark mit eingeschränkter Übertragbarkeit — die Folgerung bleibt: Tests und Review sind Pflichtschritte, keine Automatik.

Modul: Analyse-, Transformations- und KI-Werkzeuge

Typische Fallen

• Die Zielplattform steht vor der Analyse fest und sucht sich Argumente.
• Ein Weg für die ganze Anwendung statt je Teil — das kürzt die Diskussion ab und verlängert das Projekt.
• Containerisierung gilt als Modernisierung, ändert aber nichts an der Änderbarkeit; die proprietäre Serverkonfiguration zieht mit um.
• Java-Wechsel und Namensraumwechsel laufen gemeinsam — danach ist die Fehlersuche nicht mehr aufzulösen.
• Die Tests werden mitmigriert und prüfen danach nichts mehr; grün heißt dann nur, dass sie zueinander passen.
• Der Pilot ist das einfachste Stück und lehrt nichts — oder so kritisch, dass ihn niemand ausrollen will.
• Der Ausgangswert wird nie gemessen, der Erfolg ist damit unbeweisbar.
• Der alte Weg bleibt für den Notfall stehen und wird nie abgeschaltet; ohne Datum ist er in einem Jahr wieder Bestand.
• Der Werkzeuglauf findet einmal statt und wird nie wiederholt — Fortschritt wird dadurch unsichtbar.

Zum Seminar Jakarta EE modernisieren