Der Spickzettel zum Seminar Modern Java Development — für den Moment, in dem eine Migration ansteht, ein Agentenvorschlag auf dem Bildschirm liegt oder die Frage im Raum steht, was eigentlich in die Projektanweisung gehört. Zum Erlernen des Vorgehens taugt er nicht; dafür ist das Seminar da. Maßgeblich für Versionen und Support-Fenster bleibt die Dokumentation von Oracle beziehungsweise OpenJDK, für die Werkzeuge die des jeweiligen Anbieters. Jeder Abschnitt verweist auf das Modul, aus dem er stammt.
Java-Stände und Migrationsziel
| Version | Typ | Rolle |
|---|---|---|
| Java 8 | Alt-LTS | Weit verbreitet, ohne modernes Sprachniveau |
| Java 11 | Alt-LTS | Erster Schritt nach 8, oft Zwischenstation |
| Java 17 | LTS | Records und Sealed Types verfügbar |
| Java 21 | LTS | Virtual Threads, kostenfreie Updates enden 09/2026 |
| Java 25 | LTS | Aktuelles Ziel für neue und migrierte Projekte |
| Java 26 | Feature | Aktueller Stand, sechs Monate Lebensdauer |
Feature-Releases sind kein Migrationsziel für Bestandsprojekte — LTS ist es.
Modul: Modernes Java verstehen
Lohnt sich diese Modernisierung?
Die Fragen stehen in absteigender Stärke. Sie gelten unverändert auch für Vorschläge, die ein Agent macht.
| Frage | Bedeutung |
|---|---|
| Verhindert es einen Fehler? | Stärkstes Argument, meist sofort umsetzen |
| Macht es Absicht sichtbar? | Gutes Argument, wenn Lesbarkeit gewinnt |
| Entfernt es eine Fehlerquelle? | Gutes Argument, oft mit Testgewinn |
| Ist es nur kürzer? | Schwaches Argument, im Bestand nicht ausreichend |
| Berührt es viele Aufrufstellen? | Gegenargument, Aufwand gegen Nutzen wägen |
Modul: Modernes Java verstehen
Der Java-8-Bias von Sprachmodellen
Ein Großteil des öffentlich verfügbaren Java-Codes stammt aus der Java-8-Zeit. Entsprechend fallen die Vorschläge aus — lauffähig, aber von gestern.
| Vorschlag des Modells | Heute üblich |
|---|---|
| Anonyme innere Klasse | Lambda oder Methodenreferenz |
new ArrayList<>() und add | List.of(...) |
| if-else-Kette auf Typprüfung | Pattern Matching in switch |
| Datenklasse mit Gettern | Record |
Klassisches switch mit break | Switch als Ausdruck |
synchronized plus Thread-Pool | Virtual Threads, wo passend |
| Stark | Schwach |
|---|---|
| Verbreitete Framework-Muster | Hauseigene Bibliotheken |
| Standardbibliothek, ältere Teile | Zuletzt hinzugekommene APIs |
| Testgerüste und Beispieldaten | Fachliche Sonderregeln |
| Erklären vorhandenen Codes | Architekturentscheidungen |
Modul: Sprachmodelle und Java-Code
Kontext auswählen
| Trägt Aussage | Füllt nur |
|---|---|
| Die Klasse, die geändert wird | Das ganze Paket vorsichtshalber |
| Ihr Test | Alle Tests des Moduls |
| Die fachliche Schnittstelle | Generierte Klassen |
| Ein Beispiel-Datensatz | Vollständige Testdaten |
| Die Projektanweisung | Historische Dokumentation |
Modul: Sprachmodelle und Java-Code
Agentenkontext im Repository
Was ein Agent über ein Maven-Projekt wissen muss, steht überwiegend nicht im Code — und wird deshalb geraten, wenn es nirgends aufgeschrieben ist.
| Frage des Agenten | Steht im Code? |
|---|---|
| Wie baue ich nur dieses Modul? | Nein |
| Welcher Test gehört zu dieser Klasse? | Teilweise |
| Darf die API auf den Kern zugreifen? | Nein |
| Welche Java-Version gilt hier? | In der pom.xml, verstreut |
| Ist dieses Verzeichnis generiert? | Nein |
| Welche Konvention gilt für Fehler? | Nein |
Kanonische Kurzform der drei wirksamsten Abschnitte:
## Bauen und Testen
Vor Abschluss immer: mvn -q -pl <modul> -am test
Vollständig nur auf ausdrückliche Bitte: mvn -q verify
## Modulgrenzen
kern kennt keine anderen Module.
Neue Abhängigkeit zwischen Modulen: vorher fragen.
## Nicht lesen
target/, generated-sources/, *.class
## Lombok
Getter, Setter und Builder entstehen erst beim Übersetzen
und stehen nicht im Quelltext.Ohne -am scheitert der Modultest an fehlenden Abhängigkeiten. Ohne den
Lombok-Absatz hält der Agent vorhandene Methoden für fehlend.
Modul: Agentenkontext für Java-Repositories
Regeln so formulieren, dass sie wirken
| Wirkt kaum | Wirkt |
|---|---|
| Schreibe sauberen Code | Neue Datenklassen als Record |
| Achte auf Testabdeckung | Jede neue Fachmethode braucht einen Test |
| Vermeide Abhängigkeiten | Keine neue Abhängigkeit ohne Rückfrage |
| Nutze modernes Java | Zielstand Java 25; kein anonymes Inner-Class |
| Halte dich an die Architektur | kern kennt keine anderen Module |
Links steht, was man sich wünscht. Rechts, was überprüfbar ist.
Modul: Agentenkontext für Java-Repositories
Auftrag: direkt oder Analyse zuerst
| Direkter Auftrag | Analyse zuerst |
|---|---|
| Ergebnis ist Code | Ergebnis ist eine Liste mit Begründung |
| Prüfaufwand am Ende, hoch | Prüfaufwand vorn, niedrig |
| Korrektur bedeutet Neuimplementierung | Korrektur ist ein Satz |
| Umfang wird vom Agenten gewählt | Umfang wird vom Menschen gewählt |
Modul: Feature-Entwicklung mit dem Agenten
Migration schneiden
Ein Migrationsschritt ist erst dann einer, wenn er allein übersetzt, allein getestet und allein zurückgenommen werden kann.
| Schlecht geschnitten | Gut geschnitten |
|---|---|
| Alle Module auf einmal | Ein Modul, Reihenfolge nach Abhängigkeit |
| Version und Refactoring gemischt | Erst Version, dann Aufräumen |
| Bibliotheken gebündelt hochziehen | Eine Bibliothek je Schritt |
| Ohne Zwischenstand lauffähig | Nach jedem Schritt lauffähig |
| Blockertyp | Umgang |
|---|---|
| Neue Version vorhanden | Einzeln hochziehen, testen |
| Nachfolger unter neuem Namen | Wechsel als eigener Schritt |
| Aufgegeben, Ersatz vorhanden | Fachliche Bewertung nötig |
| Aufgegeben, kein Ersatz | Eigenlösung oder Modul zurückstellen |
| Hausintern, nicht gepflegt | Zuständigkeit klären, dann entscheiden |
Modul: Migration mit Coding Agents
Absicherung vor der Migration
| Lage | Konsequenz |
|---|---|
| Gute Testabdeckung im Modul | Migration kann beginnen |
| Tests vorhanden, wenig aussagekräftig | Erst nachschärfen |
| Keine Tests, Fachlogik einfach | Charakterisierungstests schreiben |
| Keine Tests, Fachlogik komplex | Zurückstellen, erst absichern |
| Verhalten nirgends dokumentiert | Fachbereich einbeziehen |
Das Netz wird nicht flächendeckend gespannt, sondern an den Stellen, an denen sich zwischen zwei Ständen tatsächlich etwas ändern kann.
| Risikostelle | Der Test prüft |
|---|---|
| Ersetzte API | Verhalten bei Sonderfällen |
| Datum und Zeitzone | Grenzwerte über Zeitumstellung |
| Zeichensatz | Umlaute und Sonderzeichen im Umlauf |
| Zahlenrundung | Halbe Werte und Nachkommastellen |
| Nebenläufigkeit | Ergebnis unter gleichzeitiger Last |
| Sortierung | Reihenfolge bei gleichen Schlüsseln |
Module: Migration mit Coding Agents · Tests und Debugging im Migrationskontext
Prüfinstanzen und Freigabegrenze
Jede Instanz prüft, was die vorherige nicht kann — nicht dasselbe noch einmal.
| Instanz | Fängt ab |
|---|---|
| Compiler | Erfundene Namen, Typfehler |
| Tests | Verhaltensänderungen |
| Statische Analyse | Muster, Stil, bekannte Fallen |
| Mensch | Fachlichkeit, Architektur, Angemessenheit |
| Änderung | Freigabe |
|---|---|
| Formatierung, Umbenennung lokal | Agent allein |
| Test ergänzen | Agent allein |
| Fachlogik ändern | Mensch prüft Diff |
| Neue Abhängigkeit | Mensch entscheidet vorher |
| Modulgrenze berühren | Mensch entscheidet vorher |
| Datenbankschema ändern | Mensch entscheidet vorher |
Modul: Qualität, Sicherheit und Firmenumgebung
Lizenz- und Herkunftsfragen
| Frage | Antwortlage |
|---|---|
| Stammt der Code aus fremdem Projekt? | Nicht feststellbar |
| Welche Lizenz gilt für das Ergebnis? | Vertraglich geregelt, nicht technisch |
| Dürfen wir es ausliefern? | Hausjuristische Frage |
| Ist die Nutzung dokumentiert? | Organisatorisch lösbar |
| Kam eine fremde Bibliothek hinzu? | Technisch prüfbar |
Nur die letzte Zeile lässt sich im Build automatisieren. Der Rest ist Organisation — kein Werkzeugproblem.
Modul: Qualität, Sicherheit und Firmenumgebung
Verbrauch senken
| Treiber | Gegenmittel |
|---|---|
| Ganze Ordner als Referenz | Einzelne Dateien benennen |
| Sehr lange Sitzungen | Verdichten oder neu beginnen |
| Wiederholte Suchläufe | Pfade direkt angeben |
| Vollständige Reaktor-Builds | Gezieltes Modul- und Testkommando |
| Große Werkzeugausgaben | Ausgabe filtern, bevor sie ankommt |
Dieselben Maßnahmen verbessern auch die Antwortqualität — hier gibt es keinen Zielkonflikt.
Modul: GitHub Copilot im Java-Projekt
Typische Fallen
- LTS heißt nicht „läuft ewig”. Auch LTS-Fenster enden; für Java 21 im September 2026.
- Laufzeitstand ist nicht Sprachniveau. Die Anwendung läuft längst auf aktueller JVM, der Code bleibt Java 8, weil die Projektkonfiguration nie nachgezogen wurde.
- Geänderte Standardwerte werfen keinen Fehler. Zeichensatz und Zeitzone ändern Verhalten still — der grüne Compiler sagt darüber nichts.
defaulthebelt die Vollständigkeitsprüfung aus. Bei Sealed Types und Pattern Matching bewusst darauf verzichten.- Attribute an bekannten Annotationen. Die Annotation gibt es, das Attribut nicht — der häufigste übersehene Fall.
- Grün heißt nicht richtig. Der Compiler prüft Typen, nicht Fachlichkeit; ein Test kann grün sein und nichts behaupten.
- Der Agent passt den Test an die Implementierung an. Ausdrücklich verlangen, Fehlschläge zu berichten statt zu umgehen.
- Namensgleichheit ist nicht Verhaltensgleichheit. Bei ersetzten APIs der gefährlichste Fall.
- Migrieren und Absichern gleichzeitig. Dann prüft der Test die neue Annahme und bestätigt nur die Änderung.
- Transitive Abhängigkeiten legen den Stand fest. Sie stehen nicht in der Konfiguration, sondern im Abhängigkeitsbaum.
Module: alle zehn Module des Seminars