Java-Modernisierung: Enterprise-Upgrades machbar machen

Betritt man ein großes Unternehmen — eine Bank, eine Fluggesellschaft, ein Telekommunikationsunternehmen — trägt Java meist die schwere Last. Kern-Banking-Systeme, Betrugserkennungs-Pipelines, Auftragsverwaltung, nächtliche Batch-Jobs, die Millionen von Transaktionen vor Sonnenaufgang abgleichen. Es funktioniert, es skaliert — und genau deshalb läuft so vieles davon noch auf Java 8 oder älter.

Funktionieren ist nicht dasselbe wie gesund sein. Frameworks liegen auf Versionen, die keine Sicherheits-Patches mehr erhalten. Die ursprünglichen Autoren sind längst weg. „Nicht anfassen, es funktioniert" hat sich zu einem Architekturprinzip verhärtet. Und die Lücke wächst weiter: Records, Sealed Classes, Pattern Matching, Virtual Threads, die G1/ZGC-Collector, bessere Container-Awareness und schnelleres Startup warten alle auf der anderen Seite eines Upgrades, das niemand einplanen möchte.

Dieser Beitrag handelt davon, diese Lücke zu schließen. Er erklärt, warum diese Anwendungen stecken bleiben, und führt dann durch die fünf Fähigkeiten des Premium Package for Java — JDK-Versions-Upgrades, Liberty-Replatforming, UI-Modernisierung, Unit-Test-Generierung und Sicherheits-Remediation — und wie jede die Arbeit zwischen deterministischer Automatisierung und AI aufteilt. Am Ende steht, was dein Repository braucht, um das Beste herauszuholen, wie du Zugang erhältst und wie du startest.

Warum so viele Java-Apps ein Jahrzehnt hinterherhinken

Wenn Modernisierung so offensichtlich sinnvoll ist, warum sehen so viele Enterprise-Java-Anwendungen noch aus wie eingefroren um 2014? Die Ursachen sind strukturell: organisatorische Trägheit und echtes Engineering-Risiko.

• Organisches Wachstum, kein geplantes Wachstum. Diese Systeme wuchsen Feature für Feature, Akquisition für Akquisition. Code-Schichten stapelten sich auf älteren Schichten, jede unter anderen Deadlines und Konventionen geschrieben. Was du heute erbst, ähnelt geologischem Sediment: Entscheidungen von Dutzenden Teams über ein Jahrzehnt.
• Die Ingenieure, die die Kernmodule schrieben, sind weitergezogen, und das implizite Wissen ging mit ihnen. Was bleibt, ist spärliche Dokumentation und ein paar Senior Engineers, die „ungefähr wissen, wie dieses Modul funktioniert".
• Ein Java-Upgrade bedeutet Dependency-Audits, Framework-Upgrades (Spring, Hibernate, Jakarta EE Namespace-Migrationen), Entfernung veralteter APIs und Revalidierung in jeder Umgebung — Monate an Aufwand, echtes Budget und echte Opportunitätskosten, schwer zu rechtfertigen, wenn das System bereits funktioniert.
• Selbst ein Java 8 → 17 oder 21 Sprung kann Modul-System-Konflikte, entfernte interne APIs (sun.misc.Unsafe), Reflection-Warnungen, die zu harten Fehlern werden, und subtile Garbage-Collector-Verhaltensänderungen aufdecken. Ein Versions-Bump auf dem Papier wird in der Praxis zu einer wochenlangen Untersuchung.
• Regressions-Zyklen sind lang. Ausgedehnte Test-Suites — Unit, Integration, Performance, UAT, manchmal manuelle Abnahmen — bedeuten, dass ein einzelnes Upgrade Wochen an Tests auslösen kann, bevor es ausgeliefert wird.
• Darunter liegt alles: die Angst, das Funktionierende zu zerstören. Wenn eine Anwendung täglich Millionen von Dollar bewegt, überwiegen die Kosten eines schlechten Deploys die Kosten des Nicht-Upgrades — also verschiebt sich das Upgrade-Gespräch aufs nächste Quartal. Und das übernächste.

Der Ausweg ist inkrementell, kein Neuschreiben. Mit den richtigen Tools kannst du die Schulden in Schritten abbezahlen, die klein genug sind, dass jeder einzelne sicher ausgeliefert werden kann.

Das Premium Package for Java

Das Premium Package for Java ist eine Suite aus fünf Workflows für die Enterprise-Java-Modernisierung. Jeder basiert auf derselben Arbeitsteilung: Deterministische Automatisierung erledigt die vorhersehbare, mechanische Arbeit, und AI übernimmt die kontextuellen Entscheidungen, die Rezepte nicht abbilden können.

Regelbasierte Engines wie OpenRewrite sind zuverlässig bei mechanischem Refactoring über Tausende von Dateien. AI ist besser für die unordentlichen Teile — Build-Fehler interpretieren, über Geschäftslogik nachdenken, zwischen Trade-offs abwägen. Bob orchestriert beides in einem schrittweisen Workflow, bei dem ein Mensch die folgenreichen Schritte genehmigt.

Das Fachwissen dahinter ist entscheidend. Die Workflows wurden von Ingenieuren von IBM und Red Hat gestaltet, die JIT-Compiler gebaut, WebSphere und Open Liberty ausgeliefert, Quarkus mitbegründet und zu OpenJDK, Jakarta EE und MicroProfile beigetragen haben. Das Tooling codiert, wie diese Teams eine Migration angehen — Wissen, das ein Modell nicht aus dem Code vor ihm rekonstruieren kann.

So läuft die Aufteilung über die fünf Fähigkeiten.

Fähigkeit 1: JDK-Versions-Upgrades — Java 8 auf 11, 17, 21 oder 25

Das JDK zu upgraden ist die häufigste Modernisierungsaufgabe und die am meisten unterschätzte. Bob behandelt sie als mehrstufige, evidenzbasierte Reise statt als einzelnen Befehl.

• Projekt-Intelligence zuerst. Bob analysiert das Build-Tool (Maven oder Gradle), die Modul-Topologie, die aktuelle Java-Version und den Framework-Footprint, schlägt dann machbare Upgrade-Pfade vor (8→17, 8→21, mit oder ohne Jakarta EE), jeweils mit einer Schwierigkeitsbewertung und den zu erwartenden technischen Herausforderungen.
• Für das gewählte Ziel erledigen kuratierte OpenRewrite-Rezepte die mechanischen Transformationen sicher und im großen Maßstab.
• Rezepte bringen dich einen Teil des Weges — in der Praxis 40–50 %. Der Rest — exotische Dependency-Konflikte, entfernte interne APIs, bibliotheksspezifische Fehler — ist, wo die agentische Schleife einsetzt. Bob kompiliert das Projekt, parst die Maven/Gradle-Build-Logs, gruppiert Ausnahmen nach Grundursache und fragt die AI nach gezielten Fixes, Modul für Modul.
• Leitplanken, die die Absicht respektieren. Die AI wird angewiesen, nie stillschweigend zwischen javax- und jakarta-Namespaces zu wechseln, nie Code auszukommentieren oder Dateien zu verschieben, um es „zum Kompilieren zu bringen", und explizite Genehmigung vor jeder Paket- oder Dependency-Änderung einzuholen.

Du erhältst ein Upgrade, das schnell ist, wo es automatisiert werden kann, und sorgfältig, wo es das nicht kann — mit einem vollständigen Audit-Trail am Ende.

Fähigkeit 2: Liberty-Replatforming — traditioneller WebSphere zu Liberty

Die Migration von traditionellem WebSphere Application Server zu WebSphere Liberty oder Open Liberty bringt dir einen geringeren Memory-Footprint, container-freundliches Packaging, schnelleren Startup und moderne Jakarta EE-Unterstützung. Es ist auch eine der aufwändigsten Migrationen, die man von Hand versuchen kann.

• AMA-gesteuertes Assessment. Bob nimmt Output vom IBM Application Modernization Accelerator auf, parst seine Berichte in spezifische, dateiebene Migrationsprobleme mit regelbasierter Remediation-Anleitung.
• Jede AMA-Regel enthält präskriptive Anleitungen — „ersetze com.ibm.websphere.* durch das Jakarta EE-Standardäquivalent", „migriere ibm-web-ext.xml-Konfiguration zu server.xml". Bob gibt diese Probleme, gruppiert nach Grundursache, zusammen mit dem Hilfetext der Regel an die AI, damit das Modell den bekannten Fix anwendet statt zu raten.
• Wo die Migration einen Jakarta-Sprung beinhaltet, übernimmt dieselbe OpenRewrite-Rezeptbibliothek die Namespace-Mechanik deterministisch.
• Build, Deploy, Verify. Bob baut das WAR/EAR, deployt über liberty-maven-plugin oder liberty-gradle-plugin, verfolgt Server-Logs auf Startup- und Class-Loading-Fehler und löst sie iterativ. Funktionale Verifikation mit curl gegen REST-Endpunkte ist Teil des Standardflows.

Der Workflow codiert, wie Liberty-Ingenieure die Migration angehen, statt es einem generischen Prompt zu überlassen.

Fähigkeit 3: UI-Modernisierung — JSP/Struts zu einem modernen SPA

Die meisten Legacy-Java-Apps treiben ihre UIs noch über JSP, Struts oder Servlets. Bob teilt dies in eine Fünf-Phasen-Pipeline auf.

• Architektur-Extraktion. Bevor Code neu geschrieben wird, analysiert Bob die Anwendung und erstellt ein architecture.md, das jeden Controller, jede Action, jeden Servlet, jede Seite, jedes Formular, jede Validierungsregel und jeden Datenfluss-Pfad katalogisiert. Dieses Dokument ist die Wahrheitsquelle für den Rest der Migration.
• Die Legacy-Präsentationsschicht (Struts-Actions, Servlets, JSP-Controller) wird in REST-Endpunkte auf einem modernen Backend — Spring Boot, Quarkus oder Liberty — konvertiert, wobei die ursprünglichen DAOs und Modell-Klassen unberührt bleiben, um die Datenbankintegrität zu schützen.
• Frontend-Scaffolding. Ein neues TypeScript-Projekt (Angular, React oder ein anderes Framework) wird mit einem gewählten Design-System — Carbon, Material UI oder shadcn/ui — verdrahtet, mit HTTP-Client, Theming, Routing, State-Management, Error-Boundaries und CORS, bevor Feature-Arbeit beginnt.
• JSP-Formulare und -Tabellen werden dann auf Design-System-Äquivalente — DataTables, Cards, DatePickers, validierte Formulare — abgebildet, mit den ursprünglichen Geschäftsregeln.
• Validierungsgates bei jedem Schritt. Bob startet die Anwendung nie selbst. Nach jeder Phase bittet es den Entwickler, den Build/Start-Befehl auszuführen und zu bestätigen, wodurch die Verifikation in menschlichen Händen bleibt.

AI übernimmt die kontextuelle Übersetzung von JSP-Tag-Soup zu modernen Komponenten; Automatisierung übernimmt Scaffolding, Dependencies und Build-Verifikation.

Fähigkeit 4: Unit-Testing — erst Strategie, dann Generierung

Test-Coverage ist oft der größte einzelne Blocker für die Modernisierung: Du kannst nicht sicher upgraden, was du nicht sicher verifizieren kannst. Bob generiert eine Test-Strategie, bevor es Tests generiert.

• Strategie-Generierung. Bob analysiert das Projekt und erstellt ein UNITTEST.md, das Architektur, Module, die Coverage benötigen, empfohlene Frameworks (JUnit 5, Mockito, AssertJ), Namenskonventionen, Coverage-Schwellenwerte und die genauen Befehle zum Ausführen von Tests mit und ohne Coverage-Reporting abdeckt.
• Kandidaten-Auswahl funktioniert auf mehreren Granularitäten — ganze Packages, spezifische Klassen, einzelne Methoden — und kann auf git-Diffs laufen, um den Aufwand auf kürzlich geänderten Code zu fokussieren.
• Generieren, Ausführen, Fixen. Jeder Test-Prompt endet mit derselben Anweisung: Führe die Tests aus, fixe die Fehler. Die AI führt aus, beobachtet Fehler und iteriert, bis die Suite grün ist, statt bei der Code-Generierung aufzuhören.
• Bob integriert mit JaCoCo, damit die Schleife auf gemessene Coverage zielt statt nur auf einen grünen Test-Run.

Automatisierung führt die Tests aus; AI schreibt sie und denkt über die Fehler nach. Die resultierende Coverage ist es, die die anderen vier Workflows freischaltet.

Fähigkeit 5: Sicherheits-Remediation — CVEs als Teil derselben Schleife

Eine modernisierte Anwendung, die noch CVE-belastete Dependencies mitbringt, ist nur halb fertig. Sicherheits-Remediation nutzt dieselbe Architektur wie das JDK-Upgrade, auf Schwachstellen gerichtet.

• Build-getriebene Erkennung. Bob nutzt die Maven- und Gradle-Log-Analyzer aus dem Upgrade-Workflow, abgestimmt darauf, Dependency-Advisories, Deprecation-Warnungen und bekannt-verwundbare transitive Dependencies aus Build-Output, Dependency-Check-Plugins und SBOM-Tools zu erkennen.
• Wenn ein Fix kein sauberer Versions-Bump ist — etwa, weil die gepatchte Bibliothek Signaturen geändert hat und die Call-Sites migriert werden müssen — gruppiert die agentische Schleife die Fehler nach Grundursache, wendet die Remediation über Module hinweg an und rebuilt zur Verifikation.
• Dieselben Leitplanken gelten. Keine Dependency-Änderungen ohne explizite Genehmigung, kein auskommentierter Code, keine Namespace-Überraschungen. Fixes werden präsentiert, erklärt und bestätigt, bevor sie landen.

Sicherheitshärtung läuft auf demselben Track wie der Rest der Modernisierungsarbeit, nicht als separater Roadmap.

Der gemeinsame Faden

Über alle fünf Fähigkeiten hinweg gilt dieselbe Arbeitsteilung:

Automatisierung übernimmt das Deterministische, AI übernimmt das Kontextuelle, und ein Mensch genehmigt das Folgenreiche — unterstützt von den IBM- und Red Hat-Ingenieuren, die die Plattform darunter gebaut haben.

Mach dein Repository bereit

Diese Workflows gehen weiter bei einer Codebasis, die bereits lesbar ist — und was Bob hilft, ist dasselbe, was jedem Ingenieur hilft, der den Code erbt:

• Ein grüner, reasonably schneller Build. Jede Schleife hier ist auf Compile- und Test-Output verankert. Je schneller und zuverlässiger dein mvn/gradle Build, desto enger der Generieren-Ausführen-Fixen-Zyklus.
• Vorhandene Tests, auch wenn teilweise. Coverage ist sowohl ein Sicherheitsnetz für Upgrades als auch ein Signal, das Bob liest. Wenn du wenig davon hast, starte mit Fähigkeit 4, bevor du einen Versions-Sprung versuchst.
• Ein gepinntes, deklariertes Dependency-Tree. Klare pom.xml/build.gradle-Versionen und ein aktueller Dependency-Lock machen den Unterschied zwischen einem sauberen Rezept-Run und einer mehrtägigen Konflikt-Suche.
• Build-Tooling, das Bob steuern kann. Die Liberty- und Sicherheits-Workflows stützen sich auf Standard-Plugins (liberty-maven-plugin, dependency-check, SBOM-Tooling); wenn sie eingerichtet sind, kann die Automatisierungs-Hälfte ihren Job machen.

So erhältst du Zugang

Das Premium Package for Java ist ein Add-on zu einem Bob-Basisplan, kein separater Download.

Wie du berechtigt wirst, hängt von deinem Plan ab:

• Individuelle Pläne (Pro, Pro+, Ultra). Gehe zur Preisseite auf bob.ibm.com, wähle einen Plan und füge das Java-Add-on beim Checkout hinzu. Nachdem du die Bestellung abgeschlossen und die Bob IDE installiert hast, wird die Berechtigung beim Login erkannt. Du verwaltest Seats und Add-ons über dein Abonnement auf bob.ibm.com.
• Enterprise-Pläne. Dein Bob-Administrator weist Basisplan-Seats und das Java-Add-on über die Bob-Admin-UI zu. Sobald dir ein Seat zugewiesen ist, gilt dieselbe automatische Erkennung — logge dich ein und die Workflows erscheinen.

Zwei Dinge, die explizit angesprochen werden sollten:

• Du musst das Java-Add-on beim Checkout auswählen. Es ist nicht standardmäßig Teil des Basisplans. Wenn du es beim Kauf überspringst, werden die Workflows nicht angezeigt, auch nicht auf einem bezahlten Plan.
• Trial-Pläne können keine Add-ons nutzen. Das Premium Package for Java erfordert einen bezahlten Pro-, Pro+-, Ultra- oder Enterprise-Plan.

Loslegen

Sobald dein Plan das Add-on enthält und du in der Bob IDE eingeloggt bist:

• Führe das JDK-Upgrade-Assessment zuerst auf einem einzelnen Modul aus, um die vorgeschlagenen Pfade und Schwierigkeitsbewertungen zu sehen, bevor du dich für ein Ziel festlegst.
• Wenn Coverage dünn ist, generiere eine UNITTEST.md-Strategie und baue ein Sicherheitsnetz, bevor du einen Versions-Sprung wagst.
• Genehmige Änderungen Modul für Modul — die Leitplanken sind dafür da, Namespace- und Dependency-Änderungen in deinen Händen zu behalten.

Sieh dir die Fallstudien auf bob.ibm.com an, wie Teams diese Migrationen von Anfang bis Ende durchgeführt haben.