Java-Migration mit KI und lokalem LLM: von Java 8 oder 11 auf 21 und 25, mit Spring Boot

Java-Migration mit lokalem LLM im Jahr 2026

Ein Java-Upgrade von 8 oder 11 auf 21 oder 25 mit einem lokalen LLM gelingt am besten in zwei Schichten. Deterministische OpenRewrite-Rezepte erledigen zuerst die mechanischen Änderungen, danach behebt ein Codemodell auf einer GPU in Ihrem eigenen Netz, was übrig bleibt: Buildfehler, entfernte APIs und fehlschlagende Tests, in einer Schleife, die nach jeder Änderung kompiliert und testet. Eine Workstation mit einer NVIDIA RTX PRO 6000 Blackwell Workstation Edition oder Max-Q betreibt ein solches Modell für ein kleines Migrationsteam. Veröffentlichte Tests zeigen, dass jeder Merge Request des Agenten weiterhin ein Review durch Ihr Entwicklungsteam braucht.

Dieser Leitfaden richtet sich an IT-Abteilungen und Softwareteams mit Dutzenden oder Hunderten Java-Diensten auf alten Versionen, deren Code nicht an ein Cloud-Werkzeug gehen darf. Er behandelt die Zielversionen, was die Rezepte tun und unter welcher Lizenz, was veröffentlichte Agenten-Tests zeigen, die Schleife je Dienst, Red Hats Weg und die Hardware für jede Phase. Unsere Leitfäden zur COBOL-Modernisierung mit lokalem LLM, zu SAP ABAP mit lokalem LLM und zu selbst gehosteten Copilot-Alternativen behandeln die benachbarten Aufgaben.

Zielversionen für Java und Spring Boot wählen

Oracles Java SE Support Roadmap, aktualisiert am 20. Oktober 2026, nennt für die LTS-Versionen (Long-Term Support), auf denen die meisten Dienste laufen, diese Daten. Oracle will nach eigener Aussage alle zwei Jahre eine LTS-Version veröffentlichen; Java 29 ist für September 2027 geplant.

Oracle Java SE Support Roadmap, Seite aktualisiert am 20. Oktober 2026, gelesen am 30. Oktober 2026; „oder später“ steht so in Oracles Fußnote. Daten des Supportangebots von Oracle; andere JDK-Distributionen veröffentlichen eigene.

Das Framework bestimmt das Ziel oft stärker als das JDK. Spring Boot 3.0 verlangte Java 17 und wechselte auf Jakarta EE 10; sein Migrationsleitfaden sagt: „Jakarta EE now uses jakarta packages rather than javax“. Auch Spring Boot 4.0 verlangt Java 17 oder neuer; die aktuelle Dokumentation zu 4.1.2 nennt Kompatibilität bis Java 27. Der Migrationsleitfaden empfiehlt, zuerst auf die neueste 3.5.x zu wechseln, und nennt Änderungen, die die meisten Dienste betreffen: Jackson 3 verschiebt seine Pakete von com.fasterxml.jackson nach tools.jackson, @MockBean und @SpyBean entfallen zugunsten von @MockitoBean und @MockitoSpyBean, Undertow fällt weg, weil es die Basis Servlet 6.1 noch nicht unterstützt, und mehrere Starter tragen neue Namen, sodass aus spring-boot-starter-web nun spring-boot-starter-webmvc wird. Ein Dienst auf Java 8 und Spring Boot 2 durchläuft also zwei Framework-Generationen und zwei Paketumbenennungen.

OpenRewrite-Rezepte erledigen den mechanischen Teil

OpenRewrite schreibt Quellcode mit Rezepten um, die auf einem Lossless Semantic Tree des Projekts arbeiten, einem vollständigen Modell von Code und Typen. Das Repository rewrite-migrate-java nennt „Java 8, 11, 17, 21, and 25“ als aktuelle LTS-Versionen und bietet je Schritt ein zusammengesetztes Rezept: Java8toJava11, UpgradeToJava17, UpgradeToJava21 und UpgradeToJava25, jedes baut auf dem vorigen auf. UpgradeToJava21 etwa führt 18 Teilrezepte der Reihe nach aus: Es wendet zuerst die Migration auf Java 17 an, hebt den Build auf Java 21, ersetzt veraltete APIs wie Thread.stop() und new URL(String), aktualisiert Build-Plugins und schreibt switch-Anweisungen mit Pattern Matching um. Der Migrationsleitfaden zu Spring Boot 3.0 nennt OpenRewrite-Rezepte unter den hilfreichen Werkzeugen.

Die Lizenzen verdienen vor Projektbeginn einen genauen Blick. Die Lizenzseite von OpenRewrite sagt, dass die Kernbibliotheken und die Plugins für Maven und Gradle unter Apache 2.0 stehen. Die LICENSE.md-Dateien der Repositories rewrite-migrate-java und rewrite-spring verweisen auf die Moderne Source Available License. Sie erlaubt Nutzung, Kopie, interne Weitergabe und abgeleitete Werke und verbietet, die Funktion der Software Dritten als Dienst bereitzustellen. Die Lizenzseite fasst zusammen: „Individual organizations can consume and apply these recipes to their source code, but the recipes cannot be put into commercial products or be re-sold.“ Sie ergänzt, dass Beratungsunternehmen ihren Kunden das Ausführen der Rezepte nicht in Rechnung stellen dürfen. Rezepte für die neuesten Releases von Spring Boot, Spring Framework und Hibernate sind laut derselben Seite für Kunden von Moderne unter der Moderne Proprietary License erhältlich; prüfen Sie daher die Lizenz jedes Rezepts, bevor Sie einen Spring-Boot-Schritt darauf aufbauen. Ein Unternehmen, das seine eigenen Dienste aktualisiert, lässt die Rezepte daher vom eigenen Team ausführen; die Einzelheiten für Ihren Fall bestätigt Ihre Rechtsberatung.

Rezepte allein bringen die Arbeit selten zu Ende. Im unten beschriebenen Benchmark FreshBrew migrierte OpenRewrites Rezept UpgradeToJava21 7,0 Prozent der Projekte nach den Erfolgsbedingungen des Benchmarks auf Java 17. Bei 69 der 228 Projekte konnte es seinen Syntaxbaum gar nicht aufbauen. Die Autoren erklären, OpenRewrite „operates deterministically; it can only apply transformations for which an explicit rule exists“, und sei dafür gebaut, Entwicklungszeit zu sparen; als autonomes Werkzeug sei es laut Paper nicht gedacht. In dieser Lücke setzt das Modell an.

Was veröffentlichte Agenten-Tests zeigen

FreshBrew ist der ausführlichste öffentliche Test von KI-Agenten bei Java-Upgrades. Die Autoren von Google, dem Max-Planck-Institut für Intelligente Systeme, dem ELLIS Institute Tübingen, Salesforce und Gologic gingen von den 30.000 Maven-Projekten mit den meisten Sternen auf GitHub aus und behielten 228, die auf Java 8 bauen und ihre Tests bestehen, auf Java 17 scheitern, mindestens 50 Prozent Testabdeckung haben und unter einer freizügigen Lizenz stehen. Eine Migration gilt nur als erfolgreich, wenn das Projekt kompiliert, alle ursprünglichen Tests unverändert bestehen und die Zeilenabdeckung um höchstens 5 Prozentpunkte sinkt, ein Schutz gegen Agenten, die fehlschlagende Tests löschen.

FreshBrew, arXiv 2510.04852v3 vom 3. Oktober 2026, gelesen am 30. Oktober 2026. Anteil der 228 Projekte mit erfolgreicher Migration; die Spalte Java 21 ist eine direkte Migration von 8 auf 21. Das Paper nennt die verwendete Größe von Qwen3 nicht. Messungen der Autoren.

Der beste Agent im Test schaffte etwa die Hälfte dieser schwierigen Projekte, jedes Ergebnis braucht also ein Review. Die damals getesteten offenen Modelle, Qwen3 und DeepSeek-V3, erreichten 10 bis 16 Prozent; bei DeepSeek-V3 gingen mehr als 70 Prozent der Fehlschläge auf das Verhalten des Agenten zurück, etwa Schleifen, erfundene Befehle und Änderungen ohne Ergebnis, während GPT-4.1 am häufigsten an Inkompatibilitäten der Java-API scheiterte. Die neueren offenen Codemodelle waren nicht Teil des Tests: Qwens Modellkarte zu Qwen3-Coder-Next nennt 70,6 auf SWE-bench Verified, einem allgemeinen Benchmark für Software-Reparatur, ein veröffentlichtes Ergebnis zur Java-Migration gibt es dafür aber nicht. Ein Pilot mit 10 bis 20 Ihrer eigenen Dienste und denselben drei Erfolgsbedingungen liefert den Wert für Ihren Code.

Die Agenten-Schleife je Dienst auf eigener Hardware

Die Arbeit je Dienst folgt denselben Schritten, und Build und Tests entscheiden über das Ergebnis mehr als das Modell.

1. Legen Sie einen Branch an und führen Sie das OpenRewrite-Rezept für den nächsten LTS-Schritt mit dem Maven- oder Gradle-Plugin aus.
2. Bauen Sie mit dem Ziel-JDK und führen Sie die Tests aus.
3. Übergeben Sie Compilerfehler und fehlschlagende Tests dem Agenten, der den Code liest, Dateien ändert und den Build erneut startet.
4. Hören Sie auf, wenn der Build grün ist und die Abdeckung nicht gesunken ist, oder nach einer festen Zahl von Versuchen, und halten Sie den Grund fest.
5. Öffnen Sie einen Merge Request, den eine Entwicklerin oder ein Entwickler wie jede andere Änderung prüft.

Der Agent ist ein beliebiges Werkzeug, das mit einem OpenAI-kompatiblen Endpunkt spricht und Befehle ausführen kann, etwa OpenCode oder Cline; unser Leitfaden zu Claude Code mit lokalem Modell zeigt, was sich ändert, wenn die CLI eines Anbieters auf Ihren eigenen Server zeigt. vLLM stellt das Modell mit Tool Calling bereit, wie unser Leitfaden zu den Tool-Calling-Parsern in vLLM erklärt. JDKs, Maven oder Gradle und ein Spiegel Ihres Artefakt-Repositorys laufen im selben Netz, damit Builds ohne Internetzugang funktionieren; unser Leitfaden zum Air-Gapped-LLM-Server zeigt die Offline-Installation der Modellseite.

Eine praktische Folge für die Dimensionierung: Solange Maven kompiliert und testet, wartet der Agent, und seine Sitzung erzeugt nichts. Wer migriert, kann daher mehrere Dienste gleichzeitig in der Schleife halten, und die GPU wird nach den Sitzungen dimensioniert, die im selben Moment Token erzeugen.

Sie können die Workstation allein bestellen, die Einrichtung von vLLM, Qwen3-Coder und einem Agenten wie OpenCode allein oder beides zusammen: die Workstation mit allem fertig installiert und eingerichtet; schreiben Sie uns, wir schlagen Ihnen die beste Lösung für Ihre Aufgaben und Ihr Budget vor.

Red Hat Developer Lightspeed for MTA

Red Hat bietet dasselbe Muster als Produkt an. Developer Lightspeed ist ein Zusatz zum Migration Toolkit for Applications (MTA), der laut Red Hats Produktseite Java-Anwendungen in der IDE umbaut, „guided by MTA's static code analysis and past migrations“, mit einer Wissensbasis früherer Korrekturen, und der Teams „the LLM of your choice–public or self-hosted–“ nutzen lässt. Laut der Seite ist der Zusatz in einem Abonnement der Red Hat Advanced Developer Suite enthalten.

Die Dokumentation zu MTA 8.3, zuletzt aktualisiert am 30. September 2026, ergänzt die Einzelheiten. Die Funktion läuft als VS-Code-Erweiterung und ist eine Technology Preview ohne Red Hats Supportbedingungen für den Produktivbetrieb. Im Agentenmodus analysiert sie den Code, wendet Korrekturen an, die die Nutzerin oder der Nutzer freigibt, kompiliert und analysiert erneut, mit „a maximum of two attempts to fix an issue“. Zu den unterstützten Anbietern zählen Cloud-Dienste, Ollama und OpenAI-kompatible Modelle in OpenShift AI oder Podman AI Lab, eingestellt in einer Datei provider-settings.yaml. Red Hat warnt selbst deutlich zur Modellwahl: Über Podman AI Lab bereitgestellte Modelle „were found to be insufficient for the complexity of code changes“, und die Qualität der Korrekturvorschläge hänge von den Fähigkeiten des LLM ab. Das Konveyor-Projekt veröffentlicht mit Kai ein verwandtes Open-Source-Werkzeug unter Apache 2.0, dessen VS-Code-Erweiterung in einem eigenen Repository liegt.

Cloud-Werkzeuge gehen den anderen Weg. AWS' Dokumentation zu Java-Upgrades mit Amazon Q Developer, gelesen am 31. Oktober 2026, nennt Upgrades von Java 8, 11 und 17 auf Java 17 und 21 für Maven-Projekte und verlangt, dass „your local network allows uploads to Amazon S3 buckets that Amazon Q uses to transform your code“. Mit einem lokalen Modell bleiben Code, Build-Logs und Prompts auf Ihrer Hardware.

Hardware für ein Migrationsteam

Die Modellwahl bestimmt die Karte. Qwen3-Coder-30B-A3B (30,5 Mrd. Parameter, 3,3 Mrd. aktiv, Apache 2.0) hat 31,2 GB FP8-Gewichte und braucht 6 GiB Cache je Sitzung mit 64K Token; Qwen3-Coder-Next (80 Mrd., 3 Mrd. aktiv, Apache 2.0) hat 80,4 GB in FP8 und nur 1,5 GiB je 64K-Sitzung, wie unser Leitfaden zum privaten Coding-Assistenten herleitet. Wir dimensionieren nach unserer Regel für Nutzer je Karte: 90 Prozent des Speichers, den der Treiber meldet, abzüglich 3 GiB pro Karte und abzüglich der Gewichte. Zusätzlich begrenzen wir jede Sitzung auf geplante 50 Token pro Sekunde aus der Speicherbandbreite der Karte, nach unserer Schätzung eine Obergrenze.

Sitzungen zu 64K Token, BF16-Cache (FP8-Cache in Klammern), nach unserer Regel für Nutzer je Karte; nutzbar 61,5 GiB (72 GB) und 83,0 GiB (96 GB) je Karte; geplant = der kleinere Wert aus Speicher und unserer Obergrenze von 50 Token pro Sekunde aus 1.344 GB/s (RTX PRO 5000), 1.792 GB/s (Workstation Edition, Max-Q) und 1.597 GB/s (Server Edition) je Karte (NVIDIA), etwa 3,3 GB (Coder-30B-A3B) und 3 GB (Coder-Next) aktive Gewichte je Token. Schätzungen, keine Messungen; Serverzeilen wie in unserem Leitfaden zum Server für Coding-Agenten.

Eine Karte. Für eine oder zwei Personen, die Dienste nacheinander abarbeiten, trägt die RTX PRO 5000 Blackwell mit 72 GB (300 W) Qwen3-Coder-30B-A3B. Die RTX PRO 6000 Workstation Edition (600 W) oder Max-Q (300 W) bietet Platz für längere Build-Logs und mehr Dienste in der Schleife; eine Workstation mit einer Workstation Edition und einem 350-W-Prozessor nimmt nach unserer Schätzung etwa 1,1 kW an der Steckdose auf (600 W plus 350 W, dazu 15 Prozent für den Rest).

Zwei Karten. Qwen3-Coder-Next, für das Qwens Modellkarte 70,6 auf SWE-bench Verified nennt, braucht zwei Karten als TP=2-Paar und lässt wegen seines kleinen Caches deutlich mehr Platz für Sitzungen. Zwei Workstation-Edition-Karten sind für diese Edition das realistische Maximum; drei oder vier Max-Q gehören nur in ein dafür gebautes Gehäuse mit starkem, gerichtetem Luftstrom.

Ein Server. Für eine geplante Welle über Hunderte Dienste trägt der Inferenzknoten auf unserer Seite zu KI-Servern mit vier RTX PRO 6000 Server Edition und 768 GB DDR5-ECC-Speicher zwei Coder-Next-Paare und nimmt nach unserer Schätzung etwa 3,4 kW auf. Nach der Welle bedient er weiter den Coding-Assistenten der Entwicklung; unser Leitfaden zum Server für Coding-Agenten dimensioniert diese Nutzung.

Wir bauen diese Workstations und Server auf Bestellung; nennen Sie uns die Zahl der Dienste, ihre Java- und Spring-Boot-Versionen und die Größe Ihres Teams, und unser Team antwortet mit einer Konfiguration.

Eine Migrationswelle planen

Eine Welle über viele Dienste geht schneller, wenn sie wie eine Fertigungslinie organisiert ist. Sortieren Sie die Dienste nach Framework und Build-Werkzeug, migrieren Sie zuerst je einen Vertreter jeder Art und machen Sie aus wiederkehrenden Korrekturen eigene OpenRewrite-Rezepte, was die Lizenz für Ihren eigenen Code erlaubt. Richten Sie die Build-Umgebung früh ein: JDK-Versionen nebeneinander, ein lokaler Artefakt-Spiegel und Build-Agenten mit genug CPU, denn Kompilieren und Testen dauern länger als das Generieren. Halten Sie für jeden Dienst fest, ob er kompilierte, ob die Tests unverändert bestanden und wie sich die Abdeckung bewegte, die drei Bedingungen von FreshBrew. Dienste mit dünner Testabdeckung brauchen vor dem Upgrade zusätzliche Tests; wie ein lokales Modell sie schreibt, zeigt unser Leitfaden zur KI-Testgenerierung on-premise. Bei Diensten, deren Autoren gegangen sind, verschafft ein erzeugtes Code-Wiki aus einem selbst gehosteten DeepWiki zuerst einen Überblick. Prompts und Antworten enthalten Quellcode; legen Sie daher vor dem ersten Lauf fest, ob Ihr Gateway sie protokolliert. Unser Leitfaden zum LLM-Gateway mit Schlüsseln und Abfrageprotokoll beschreibt die Möglichkeiten.

Der Pilot mit 10 bis 20 Diensten kann auf einer Workstation beginnen; erzählen Sie uns von Ihren Diensten, und wir schlagen die Konfiguration vor, die zum Pilot, zur späteren Welle und zu Ihrem Budget passt.

FAQ