Author
🔍 FAQ
1. Wie lässt sich Java-Code mit KI modernisieren?
KI-Tools wie Claude Code können bestehenden Java-Code analysieren und auf moderne Sprachfeatures und APIs umstellen. Dazu gehören beispielsweise Java Records, das Stream API, Text Blocks oder moderne Switch Expressions. Wichtig sind klare Coding-Richtlinien, automatisierte Tests und eine sorgfältige Überprüfung der Änderungen.
2. Welche Vorteile bietet KI bei der Java-Modernisierung?
KI kann die Modernisierung von Java-Anwendungen erheblich beschleunigen und den manuellen Aufwand reduzieren. Sie unterstützt Entwicklungsteams dabei, veraltete Konstruktionen zu ersetzen, Code besser lesbar zu machen und neue Java-Features einzusetzen. Da KI nichtdeterministisch arbeitet, müssen die Ergebnisse jedoch kontrolliert werden.
3. Was ist der Unterschied zwischen OpenRewrite und Claude Code?
OpenRewrite ist ein deterministisches Refactoring-Tool, das Java-Code anhand definierter Transformationsregeln, sogenannter Recipes, modernisiert. Claude Code nutzt dagegen Large Language Models (LLMs), um auch komplexere Codeänderungen vorzunehmen. Während OpenRewrite vorhersehbare Ergebnisse liefert, bietet Claude Code größere Flexibilität. Beide Ansätze lassen sich sinnvoll kombinieren.
4. Wie kann man Java-Anwendungen von Java 8 auf Java 25 migrieren?
Bei der Migration von Java 8 auf Java 25 müssen nicht nur die Java-Version und die Build-Konfiguration aktualisiert werden. Auch bestehender Code kann moderne Sprachfeatures und APIs nutzen. KI-Tools wie Claude Code helfen beispielsweise dabei, Klassen in Records umzuwandeln, Schleifen durch Stream-Operationen zu ersetzen und veraltete Methodenaufrufe zu modernisieren. Automatisierte Tests stellen sicher, dass das erwartete Verhalten erhalten bleibt.
5. Welche Rolle spielen Skills bei der Java-Modernisierung mit Claude Code?
Skills sind Dateien mit projektspezifischen Anweisungen, Coding-Konventionen und Best Practices. Über eine SKILL.md-Datei lässt sich beispielsweise festlegen, dass Claude Code Java 25 verwenden, Immutability bevorzugen und moderne Sprachfeatures einsetzen soll. Durch die kontinuierliche Anpassung dieser Richtlinien können Entwicklungsteams die Qualität und Konsistenz der KI-generierten Änderungen verbessern.
6. Wie lässt sich das Risiko beim KI-gestützten Java-Refactoring minimieren?
Eine zuverlässige Testbasis ist entscheidend, damit die Modernisierung das Verhalten der Anwendung nicht unbeabsichtigt verändert. Vor dem Refactoring sollten alle Tests erfolgreich durchlaufen und Änderungen in der Versionsverwaltung gesichert sein. Anschließend empfiehlt es sich, zunächst den Anwendungscode und erst danach die Tests zu modernisieren. Zusätzlich sollten alle KI-generierten Änderungen durch Code-Reviews überprüft werden.
Author
🔍 FAQ
1. Was ist neu in Java 27?
Java 27 bringt neun JEPs. Zu den wichtigsten Neuerungen gehören Compact Object Headers als Standard, G1 als Default Garbage Collector in allen Umgebungen, ein hybrider Post-Quantum-Schlüsselaustausch für TLS 1.3 und die automatische Schwärzung sensibler Daten im Java Flight Recorder. Weitere Features wie Structured Concurrency, Lazy Constants und Primitive Type Patterns befinden sich weiterhin im Preview-Status.
2. Wann wurde Java 27 veröffentlicht?
Java 27 wurde am 15. September 2026 veröffentlicht.
3. Ist Java 27 eine LTS-Version?
Nein. Java 27 ist kein Long-Term-Support-Release. Java 25 ist die aktuelle LTS-Version. Die nächste LTS-Version soll Java 29 im September 2027 werden.
4. Muss Anwendungscode für Java 27 angepasst werden?
Viele der wichtigsten Neuerungen funktionieren ohne Änderungen am Anwendungscode. Dazu gehören Compact Object Headers, G1 als Standard-Garbage-Collector sowie die Unterstützung hybrider Post-Quantum-Verfahren in TLS 1.3. Bei JVM-nahen Tools, Agents, Preview-Features und bestimmten entfernten APIs kann eine Prüfung beziehungsweise Anpassung jedoch notwendig sein.
5. Welche Preview-Features enthält Java 27?
Java 27 enthält unter anderem Lazy Constants, Primitive Types in Patterns, Structured Concurrency und das PEM API als Preview-Features. Das Vector API befindet sich weiterhin im Inkubator-Status.
Author
🔍 Frequently Asked Questions (FAQ)
1. Was ist W-JAX Together?
W-JAX Together ist ein neues Diskussionsformat der W-JAX, das den Austausch über Themen aus dem Konferenzprogramm vertieft. Teilnehmende, Speaker und Expert können offene Fragen diskutieren, eigene Erfahrungen einbringen und unterschiedliche Perspektiven miteinander vergleichen.
2. Wie funktioniert W-JAX Together?
W-JAX Together nutzt moderierte Gesprächsformate und festgelegte Spielregeln, um einen strukturierten und möglichst partizipativen Austausch zu ermöglichen. Je nach Thema kommen unterschiedliche Methoden zum Einsatz, die regeln, wie Themen ausgewählt werden, wer zu Wort kommt und wie Ergebnisse zusammengeführt werden.
3. Welche Methoden werden bei W-JAX Together eingesetzt?
Bei W-JAX Together kommen unter anderem Lean Coffee, UX Fishbowl und Liberating Structures zum Einsatz. Zu den beschriebenen Methoden gehört außerdem 1-2-4-All, bei der Teilnehmende zunächst allein über eine Frage nachdenken und ihre Gedanken anschließend in immer größeren Gruppen zusammenführen.
4. Was ist Lean Coffee und wie wird es bei W-JAX Together genutzt?
Bei einem Lean Coffee bringt die Gruppe selbst Themen für die Diskussion ein und priorisiert sie gemeinsam. Dadurch bestimmen die Teilnehmenden mit, welche Fragen und Erfahrungen im Rahmen von W-JAX Together ausführlicher diskutiert werden.
5. Welchen Nutzen hat W-JAX Together für den Arbeitsalltag?
Die bei W-JAX Together eingesetzten Methoden können auch in eigenen Teams und Projekten verwendet werden. Wer beispielsweise Lean Coffee, eine Fishbowl oder eine Liberating Structure auf der W-JAX erlebt, erhält damit praktisches Handwerkszeug für strukturierte und partizipative Diskussionen im Arbeitsalltag.
6. Wer kann an W-JAX Together teilnehmen?
An W-JAX Together können Teilnehmende der W-JAX mitmachen, die ein Thema weiterdiskutieren, eine eigene Frage einbringen oder einer Diskussion zunächst zuhören möchten. Eigene Erfahrungen, Beiträge und Ideen sind ausdrücklich erwünscht; die Formate finden parallel zu den Vorträgen der Hauptkonferenz statt.
Author
🔍 Frequently Asked Questions (FAQ)
1. Was ist Spring AI und wofür wird es verwendet?
Spring AI abstrahiert die APIs und Konfigurationsparameter verschiedener LLM-Anbieter. Interfaces wie ChatClient und ChatModel bieten ein einheitliches API und erleichtern dadurch den Wechsel zwischen Modellen und Anbietern.
2. Wie ruft man ein LLM mit Spring AI 2.0 auf?
Für den Aufruf eines LLM benötigt eine Spring-Boot-Anwendung einen modellspezifischen Spring-Boot-Starter und die entsprechende Modellkonfiguration. Über ChatClient lässt sich anschließend ein Prompt erstellen und entweder mit stream() reaktiv oder mit call() blockierend ausführen.
3. Was ist der Unterschied zwischen System-Prompt und User-Prompt?
Der System-Prompt definiert die Rolle des Modells und allgemeine Vorgaben wie Schreibstil, Zielgruppe oder Einschränkungen. Der User-Prompt enthält dagegen die konkrete Anfrage, die das LLM bearbeiten soll.
4. Wie funktioniert Chat Memory in Spring AI?
Ein LLM ist zustandslos und kennt vorherige Nachrichten nicht automatisch. Spring AI speichert deshalb über Chat Memory relevante Nachrichten einer Konversation und fügt sie bei späteren Modellaufrufen erneut dem Prompt hinzu.
5. Was sind Advisors in Spring AI?
Advisors bilden eine Verarbeitungskette um den Aufruf eines ChatModel. Sie können einen Prompt vor dem Modellaufruf verändern und die erzeugte Antwort anschließend prüfen oder anpassen, wodurch sich Funktionen wie Chat Memory, Logging oder Guardrails von der eigentlichen Anwendungslogik trennen lassen.
6. Wie funktioniert Structured Output mit Spring AI?
Mit Structured Output kann Spring AI eine LLM-Antwort direkt in einen definierten Java-Typ überführen. Dafür erzeugt Spring AI aus dem gewünschten Typ ein JSON-Schema, das die erwartete Antwortstruktur beschreibt, und wandelt das Modellergebnis anschließend mit Jackson in das entsprechende Java-Objekt um.
🔍 Frequently Asked Questions (FAQ)
1. Wird AI Softwareentwickler:innen ersetzen?
Nach Venkat Subramaniam macht ein leistungsfähigeres Werkzeug Softwareentwickler:innen nicht überflüssig. Er verweist auf Offshoring und die Automatisierung von Tests als Beispiele dafür, dass neue Technologien Aufgaben verändern und erweitern, statt ganze Berufsbilder verschwinden zu lassen. AI verändert daher die Art, wie Software entwickelt wird, während technisches Urteilsvermögen und Erfahrung weiterhin entscheidend bleiben.
2. Welche Rolle spielt AI in der Softwareentwicklung?
AI kann Aufgaben wie das Schreiben von Code oder das Erstellen von Prototypen deutlich beschleunigen. Subramaniam zufolge liefert AI vor allem Geschwindigkeit, während Entwickler:innen weiterhin entscheiden müssen, was gebaut werden soll, wie Ergebnisse zu bewerten sind und ob eine Lösung den technischen Anforderungen entspricht.
3. Warum ist Disziplin bei AI-gestützter Softwareentwicklung wichtig?
Subramaniam bringt es auf die Formel: Geschwindigkeit plus Disziplin ist Agilität, Geschwindigkeit ohne Disziplin kann zur Katastrophe werden. Weil AI Software sehr schnell erzeugen kann, müssen Entwickler:innen umso stärker darauf achten, dass Lösungen zuverlässig, sicher, performant und nachhaltig sind.
4. Welche Fähigkeiten brauchen Softwareentwickler:innen im Zeitalter von AI?
Für Subramaniam sind vor allem Grundlagen und kritisches Denken entscheidend. Entwickler:innen müssen verstehen, was produktive Software in Bezug auf Performance, Sicherheit, Zuverlässigkeit und Resilienz benötigt, und gleichzeitig beurteilen können, ob ein von AI erzeugtes Ergebnis tatsächlich sinnvoll ist oder ob es einen besseren Ansatz gibt.
5. Wie kann AI technische Entscheidungen und Prototyping verbessern?
AI ermöglicht es, Ideen wesentlich schneller als früher in funktionierende Prototypen zu überführen. Subramaniam beschreibt im Interview, wie er eine Kundenidee innerhalb von zehn Minuten mit AI umsetzte, sodass beide Seiten die Lösung konkret beurteilen und anschließend schnell verwerfen konnten. So können technische Diskussionen stärker auf funktionierenden Modellen statt auf theoretischen Argumenten basieren.
6. Warum müssen Entwickler:innen AI-generierten Code kritisch prüfen?
Subramaniam zufolge ersetzt AI die Ausführung bestimmter Aufgaben, nicht aber das notwendige Wissen und die Verantwortung der Entwickler:innen. Sie müssen weiterhin erkennen können, wann eine Lösung fehlerhaft ist, technische Anforderungen nicht erfüllt oder ein besserer Ansatz möglich wäre. Deshalb plädiert er dafür, AI-Ergebnisse konsequent und besonders kritisch zu überprüfen.
Author
🔍 Frequently Asked Questions (FAQ)
1. Was ist AOT-Caching mit Project Leyden?
Project Leyden verlagert wiederholbare JVM-Arbeit aus dem Startpfad in einen kontrollierten Trainings- und Build-Kontext. Dabei werden Informationen über geladene und gelinkte Klassen sowie, ab JDK 25, Profiling-Daten heißer Methoden in einem AOT-Cache gespeichert. Beim späteren Start kann die JVM diese Informationen wiederverwenden, ohne ihre dynamischen Eigenschaften aufzugeben.
2. Wie beschleunigt Project Leyden den Start von Java-Anwendungen?
Der AOT-Cache reduziert Arbeit, die sonst bei jedem JVM-Start erneut ausgeführt werden müsste, beispielsweise beim Laden und Linken von Klassen. Dadurch können sowohl die Zeit bis zur Betriebsbereitschaft (t_ready) als auch der anschließende Warm-up bis zum stabilen Lastzustand (t_steady) sinken. Für Spring PetClinic beschreibt der Artikel beispielsweise eine Reduktion der Startzeit von rund drei auf etwa eine Sekunde durch CDS und AOT-Cache.
3. Wie unterscheidet sich Project Leyden von GraalVM Native Image und CRaC?
Project Leyden optimiert den Start innerhalb der klassischen JVM und behält deren dynamisches Verhalten bei. GraalVM Native Image erzeugt dagegen ein natives Binary mit sehr schnellem Kaltstart, verwendet dafür aber eine Closed-World-Annahme und benötigt zusätzliche Konfiguration für dynamische Java-Features. CRaC erreicht schnelle Restores über Prozess-Snapshots, bringt jedoch zusätzliche Linux-, CRIU- und Snapshot-Komplexität mit sich.
4. Wie funktioniert AOT-Caching mit Spring Boot?
Für Spring Boot sollte die Anwendung zunächst in ein extrahiertes Layout überführt werden, da ein klassisches Fat JAR für den AOT-Cache-Pfad ungünstig ist. Ein reproduzierbarer Trainingslauf kann anschließend mit spring.context.exit=onRefresh und -XX:AOTCacheOutput bis zum Context Refresh ausgeführt werden. In der Runtime wird der erzeugte Cache mit -XX:AOTCache=... geladen, ohne dass dafür Cache-spezifischer Anwendungscode erforderlich ist.
5. Welche Bedingungen müssen AOT-Training und Runtime erfüllen?
AOT-Caches sind eng an ihre technische Umgebung gebunden. Training und Runtime müssen unter anderem hinsichtlich JDK, Hardware-Architektur und Artefaktstruktur konsistent sein; außerdem sollten reproduzierbare JAR-Inhalte und Timestamps verwendet werden. Änderungen an Code, Dependencies, JDK oder Build-Artefakten erfordern deshalb einen neuen Cache.
6. Wann lohnt sich AOT-Caching für Java nicht?
AOT-Caching lohnt sich vor allem dann, wenn der Start-up-Pfad reproduzierbar und im Verhältnis zur Lebensdauer einer Instanz relevant ist. Sehr kurzlebige CLI- oder Batch-Anwendungen profitieren häufig zu wenig, während bei selten gestarteten, langlebigen Monolithen CDS ausreichen kann. Für Serverless-Anwendungen mit extremen Sub-Sekunden-Anforderungen nennt der Artikel GraalVM Native Image als passendere Alternative.
Author
🔍 Frequently Asked Questions (FAQ)
1. Warum wird taktisches DDD durch KI-Coding-Agents wichtiger?
KI-Coding-Agents können in kurzer Zeit syntaktisch korrekten und lauffähigen Code erzeugen. Bei ungenauen Spezifikationen schließen sie fachliche Lücken jedoch möglicherweise auf statistisch plausible, aber fachlich falsche Weise. Taktisches DDD verankert Geschäftsregeln und Invarianten deshalb direkt in der Struktur des Codes.
2. Welche Rolle übernehmen Entwickler bei KI-gestützter Softwareentwicklung?
Entwickler schreiben zunehmend weniger einzelne Codezeilen und übernehmen stärker die Rolle von Architekten und Prüfern. Sie müssen Spezifikationen präzisieren und bewerten, ob generierter Code fachlich korrekt, architektonisch konsistent und langfristig wartbar ist. Dafür wird ein tiefes Verständnis der Domäne und des Softwaredesigns wichtiger als die reine Beherrschung der Programmiersyntax.
3. Warum reicht eine hohe Testabdeckung für KI-generierten Code nicht aus?
Eine hohe Testabdeckung kann Fehler sichtbar machen, aber kein schlechtes Softwaredesign reparieren. Ein fehlgeschlagener Test zeigt zunächst nur ein Symptom und beantwortet nicht, ob ein technisches Detail oder das zugrunde liegende fachliche Modell fehlerhaft ist. Ohne eine nachvollziehbare Code-Struktur bleiben strukturelle Erosion und logische Inkonsistenzen schwer erkennbar.
4. Warum bleibt der Code die stabilere Source of Truth als die Spezifikation?
Die Spezifikation beschreibt die beabsichtigte Funktionsweise eines Systems, während der Code die tatsächlich ausgeführte Laufzeitrealität bestimmt. Spezifikationen können mehrdeutig oder veraltet sein, und generative Modelle liefern nicht vollständig deterministische Ergebnisse. Typisierter und kompilierter Code kann fachliche Regeln dagegen durch Value Objects, Aggregates, Assertions und Invarianten verbindlich durchsetzen.
5. Wie unterstützt taktisches DDD die Arbeit von Coding-Agents?
Taktisches DDD definiert klare Verantwortungsgrenzen und kapselt Fachlogik in Bausteinen wie Aggregates, Value Objects und Domain Services. Ubiquitous Language und Intention-Revealing Interfaces geben dem Coding-Agent semantisch eindeutige Vorgaben. Gleichzeitig reduzieren kleine, klar abgegrenzte Kontexte die Gefahr von Kontextverlust und unnötigen Agenten- und Werkzeugzyklen.
6. Für welche Softwareprojekte eignet sich taktisches DDD besonders?
Taktisches DDD eignet sich besonders für komplexe, langlebige oder kritische Systeme, deren Geschäftsregeln und Datenintegrität dauerhaft geschützt werden müssen. Dazu gehören beispielsweise Finanzsysteme, Logistik-Plattformen, Versicherungsanwendungen, E-Government-Systeme und Lösungen für den Energiesektor. Für einfache Webanwendungen, Daten-Pipelines oder kurzlebige Prototypen kann der zusätzliche Modellierungsaufwand dagegen unverhältnismäßig sein.
Author
🔍 Frequently Asked Questions (FAQ)
1. Was bedeutet „Design before Implementation“ in der Softwareentwicklung?
„Design before Implementation“ beschreibt den Ansatz, fachliche Abläufe und Systemverhalten zunächst präzise zu spezifizieren, bevor Code geschrieben wird. Ziel ist es, Missverständnisse zu vermeiden und eine belastbare Grundlage für Entwicklung, Tests und spätere Änderungen zu schaffen.
2. Warum werden Spezifikationen durch KI wichtiger statt überflüssig?
Große Sprachmodelle können Code generieren, benötigen dafür jedoch klare und strukturierte Vorgaben. Je komplexer ein Softwaresystem ist, desto wichtiger werden präzise Spezifikationen, damit KI-Systeme konsistente und fachlich korrekte Ergebnisse liefern.
3. Was ist Spec-driven Development?
Spec-driven Development ist ein Entwicklungsansatz, bei dem Spezifikationen die zentrale Grundlage für Implementierung, Tests und Wartung bilden. Anstatt direkt aus Anforderungen zu programmieren, werden Abläufe und Geschäftsregeln zunächst in strukturierter Form beschrieben und anschließend umgesetzt.
4. Welche Vorteile bieten detaillierte Spezifikationen für Enterprise-AI-Projekte?
Detaillierte Spezifikationen schaffen ein gemeinsames Verständnis zwischen Fachbereichen, Entwicklern und Testern. Sie reduzieren Fehlinterpretationen, ermöglichen frühzeitiges Feedback und liefern sowohl Menschen als auch KI-Systemen eine zuverlässige Basis für die Implementierung.
5. Was sind Aktogramme und wofür werden sie eingesetzt?
Aktogramme sind eine Weiterentwicklung klassischer Struktogramme für die Spezifikation von Softwareabläufen. Sie verbinden gute Lesbarkeit für Menschen mit einer klaren Struktur, die auch von KI-Systemen maschinell ausgewertet werden kann.
6. Kann KI selbst Softwarearchitektur und Spezifikationen erstellen?
KI kann bei der Analyse, Validierung und Überarbeitung von Entwürfen unterstützen. Die eigentliche Entwurfsarbeit erfordert jedoch fachliches Verständnis, analytisches Denken und die Abstimmung zwischen Stakeholdern. Deshalb bleiben Menschen für Architekturentscheidungen und Spezifikationen zentral.
Author
🔍 Frequently Asked Questions (FAQ)
1. Was ist Golden Master Testing und woher kommt der Name?
Der Begriff „Golden Master" stammt aus der Softwareverteilung – die finale, freigegebene Version eines Produkts. Im Testing-Kontext bezeichnet er einen Snapshot des aktuellen Systemverhaltens: Für definierte Eingaben wird die Ausgabe aufgezeichnet und als Referenz für zukünftige Vergleiche genutzt.
2. Wann sollte ich Golden Master Testing einsetzen?
Immer dann, wenn ein System migriert oder refaktoriert werden muss, aber fachliches Wissen fehlt – weil Dokumentation veraltet ist, Domänenexperten das Unternehmen verlassen haben oder Tests kaum vorhanden sind.
3. Wie unterscheidet sich Golden Master Testing von klassischen Unit- oder Integrationstests?
Klassische Tests prüfen, ob ein Ergebnis fachlich korrekt ist. Golden-Master-Tests prüfen nur, ob sich das Ergebnis verändert hat. Sie setzen kein fachliches Verständnis voraus – das System wird als Blackbox behandelt.
4. Wo setze ich Golden-Master-Tests am besten an?
An öffentlich sichtbaren Schnittstellen: externe APIs, Batch-Programme, Dateischnittstellen oder fachliche Services. Interne Hilfsfunktionen sind ungeeignet – sie ändern sich bei Refactorings zwangsläufig und machen Tests fragil.
5. Was tue ich, wenn mein System nichtdeterministisches Verhalten zeigt?
Instabile Ausgaben wie Zeitstempel, zufällige IDs oder schwankende Sortierungen müssen aktiv neutralisiert werden – zum Beispiel durch Maskierung oder feste Referenzwerte. Ein instabiler Golden Master ist gefährlicher als keiner, weil er falsche Sicherheit vermittelt.
6. Kann KI beim Aufbau von Golden-Master-Tests helfen?
Ja, sehr effektiv. KI kann Legacy-Code und Schnittstellen analysieren, typische Eingaben ableiten und Testfälle skaliert generieren – auch für selten genutzte, aber kritische Ablaufpfade. Die fachliche Bewertung von Abweichungen bleibt jedoch Aufgabe des Teams.
7. Wann kann ich Golden-Master-Tests wieder abschaffen?
Sobald fachliche Regeln explizit verstanden, modelliert und durch gezielte Unit- oder Integrationstests abgesichert sind. Golden-Master-Tests sollten schrittweise ersetzt werden – ihr größter Erfolg ist, dass sie sich selbst überflüssig machen.




