Shiwen Dialog Folge 16 | Java 27 Release: Im Zeitalter von AI-generiertem Code, womit beschäftigt sich diese alte Sprache?

Auftakt: Eine ruhige E-Mail und die wie gewohnt eingereichte halbjährliche Hausarbeit einer fast dreißigjährigen Sprache

Am 15. September sandte OpenJDK-Chefingenieur Mark Reinhold eine kurze Nachricht an die announce-Mailingliste: JDK 27 ist offiziell GA, Build 35. Vom RC2 am 20. August bis zur finalen Version trat kein einziger weiterer P1-Bug auf. Die GPLv2-lizenzierten OpenJDK-Builds konnten noch am selben Tag unter jdk.java.net/27 heruntergeladen werden. Im Jahr 2026, in dem AI-Programmierwerkzeuge fast wöchentlich aktualisiert werden, reicht diese fast dreißigjährige Sprache wie gewohnt alle sechs Monate ihre Hausarbeit ein – diesmal nur 9 JEPs, keine spektakuläre neue Syntax, so ruhig wie eine routinemäßige Wartung.

Aber die Details sind es wert, genauer betrachtet zu werden. Von den 9 JEPs sind die zwei Änderungen, die sich am direktesten auf den Geldbeutel der Nutzer auswirken, zufällig beide nicht syntaktischer Natur: Der G1-Garbage-Collector wird in allen Umgebungen zum Standard (JEP 523), Compact Object Headers werden standardmäßig aktiviert (JEP 534) – beides spart Speicher. Gleichzeitig hält der post-quanten hybride Schlüsselaustausch Einzug in TLS 1.3 (JEP 527) – eine Änderung, die offensichtlich für die Zeit in zehn Jahren gedacht ist. Auf der anderen Seite: Primitive Types Pattern Matching in der 5. Preview, Structured Concurrency in der 7. Preview, die Vector API hat es bis zur 12. Incubator-Version geschafft – manche nennen das Gründlichkeit, andere nennen es Schlepperei.

Shiwen: In einer Zeit, in der AI Code in rasantem Tempo schreibt, veröffentlicht Java so eine Version – was ist deine erste Reaktion?

Yongliang: Nicht »Läuft Java noch oder nicht«, sondern »Diese zwei Dinge wurden endlich als Standard festgelegt«. Änderungen, die Speicher sparen, beeindrucken mich mehr als neue Syntax – ich leite die Technik bei einer Klinikgruppe in Tianjin und habe hunderte JVM-Dienste unter mir; je kleiner der Heap, desto schlanker die Rechnung. Wie viele Runden die Previews gedreht haben, darüber kommen wir noch zu sprechen.

Shiwen: Dann lassen wir es uns richtig ausdiskutieren: ob es altmodisch ist, in der Ära der AI-Programmierung noch Java zu schreiben, ob der Preview-Marathon Gründlichkeit oder Schlepperei ist, warum in dieser Version die zwei Standard-Einstellungen das Wichtigste sind, warum AI-Firmen nicht über die Post-Quanten-Ausrichtung reden, und drei konkrete Ratschläge für die, die im Java-Ökosystem bleiben.

Q1：In der KI-Programmier-Ära – ist es rückständig, noch Java zu schreiben?

Yongliang: Nicht rückständig, sondern Arbeitsteilung. Je schneller KI schreibt, desto stärker werden die Maschinen belastet, die diesen Code ausführen. Und genau das Fundament, das Java in dreißig Jahren aufgebaut hat, ist jenes, das «dafür sorgt, dass der Code nicht aus dem Ruder läuft».

KI-Werkzeuge haben die Geschwindigkeit des Code-Schreibens um eine Größenordnung gehoben. In meinem Team nutzen bereits über die Hälfte der Mitarbeiter KI zum Programmieren – darüber gibt es nichts zu beschönigen. Doch eine Tatsache wird oft übersehen: Je mehr KI schreibt, desto stärker werden die Maschinen belastet, die diesen Code ausführen. Generierter Code läuft nicht von selbst – er belegt Speicher, muss garbage-collected werden und muss um zwei Uhr nachts geplante Aufgaben überstehen. Ich arbeite bei einer Klinikgruppe in Tianjin; die Systeme für Registrierung, Bezahlung und Labortests laufen größtenteils auf der JVM, und einige davon existieren länger als die meisten KI-Unternehmen. Der Wert von Java lag nie in der Aktualität seiner Syntax – ganz ehrlich, die Syntax gehört stets zur Kategorie «brauchbar, aber unschön» – sondern im dreißigjährigen Betriebsfundament: ausgereifte Garbage Collector, Observation-Werkzeuge, die sich Zeile für Zeile analysieren lassen, und eine Community, in der man bei Problemen sucht und sofort eine Antwort findet. Die Frage «In der KI-Programmier-Ära ist es rückständig, noch Java zu schreiben?» ist also falsch gestellt. Die tatsächliche Arbeitsteilung lautet: KI ist dafür zuständig, den Code zu schreiben; die JVM ist dafür zuständig, dass der Code nicht aus dem Ruder läuft. Die Hürde beim Code-Schreiben sinkt, die Hürde, das System fehlerfrei zu halten, ist nie gesunken. Für ein System, das fünfzehn Jahre laufen soll, ist «rückständig» manchmal einfach ein anderer Name für «zuverlässig».

Q2: Ein Feature fünfmal als Preview, eine Nebenläufigkeit in sieben Runden poliert, eine API in zwölf Versionen inkubiert – ist das Gründlichkeit oder Verzögerung?

Yongliang: Java und die AI-Branche wetten auf zwei verschiedene Dinge. AI setzt auf ‘erst ausliefern, dann korrigieren’, Java setzt auf ‘der Preis eines Fehlers ist weit größer als ein späteres Erscheinen’. Beide Wetten sind richtig, vorausgesetzt, man kann es sich leisten zu verlieren.

Sprechen wir zuerst über die Einsätze beider Seiten. Die AI-Branche setzt auf ‘erst ausliefern, dann korrigieren’: Bei dialogbasierten Produkten kostet ein Fehler eine schlechte Antwort – man schließt, öffnet neu, und die Sache ist erledigt, deshalb sind wöchentliche oder sogar tägliche Updates sinnvoll. Java setzt auf eine andere Richtung: Einmal finalisierte Sprachspezifikationen sind dauerhaft – Type Erasure bei Generics wird seit über zwanzig Jahren bemängelt und nicht zurückgenommen, die Debatte um Checked Exceptions tobt von JDK 5 bis heute. Bei einer unwiderruflichen Entscheidung ist es rational, einige Jahre länger zu polieren – keine Verzögerung. Und der ‘Preview’-Mechanismus selbst ist ein Mittel gegen Verzögerung: Er ermöglicht Millionen von Nutzern in Produktionsumgebungen, ein Feature vor der Finalisierung in der Praxis zu erproben, und das Feedback fließt direkt in die Spezifikation ein. Structured Concurrency wurde von Version 1 bis Version 7 poliert – korrigiert wurden genau die Fallstricke, die echte Nutzer aufgedeckt hatten. Natürlich ist der Preis real: Primitive Types Pattern Matching, das Sie dieses Jahr schon wollten, muss noch einige Versionen warten, bis es final wird. Meine Haltung ist unmissverständlich: Wenn Sie ein Startup sind, wird Sie dieses Tempo ersticken – zwingen Sie sich nicht dazu; wenn Sie ein System pflegen, das fünfzehn Jahre leben soll, werden Sie dankbar sein, dass jemand für Sie langsam macht – ein Feature, das drei Jahre später kommt, ist besser als ein Fehler, der ein Leben lang begleitet.

Q3: Warum ist in dieser Version nicht die neue Syntax das Wichtigste, sondern die beiden speichersparenden Standardoptionen?

Yongliang: Weil die echten Schmerzpunkte von Unternehmen auf der Rechnung liegen, nicht in der Syntax. Von den 9 JEPs sind die beiden mit dem direktesten Einfluss auf den Geldbeutel zufällig beide solche, die Speicher sparen – das ist absolut kein Zufall, sondern wird durch das Nutzerprofil dieser Sprache bestimmt.

Schauen wir uns zunächst die Versionsstruktur an. Java 25 ist die LTS-Version vom September letzten Jahres, 27 ist eine Nicht-LTS-Version, die nächste LTS-Version wird voraussichtlich JDK 29 sein. Für Unternehmen finden echte Groß-Upgrades nur bei LTS-Versionen statt, daher werden die meisten neuen Funktionen in 27 in Produktionsumgebungen erst mit Version 29 wirklich genutzt. Warum also ist 27 wichtig? Weil es zwei speichersparende Maßnahmen zum Standardverhalten macht. Erstens: G1 wird zum Standard-Garbage-Collector für alle Umgebungen – früher war die Wahl des GC eine technische Entscheidung, die gerechtfertigt werden musste, jetzt muss man nicht mehr wählen, und bei großen Heaps ist dieser nach Pausenzielen optimierte Collector sofort einsatzbereit. Zweitens: Kompakte Objekt-Header werden standardmäßig aktiviert, was den Speicherbedarf des Headers jedes Java-Objekts deutlich reduziert. Beide Funktionen sind nicht glamourös, aber sie ändern direkt die Rechnung: Eine Krankenhausgruppe betreibt Hunderte von JVM-Diensten, und wenn die Heap-Auslastung um zehn Prozent sinkt (meine persönliche Schätzung, keine offizielle Zahl), spart das bares Geld bei Speicherbeschaffung und Cloud-Kosten. Syntax-Zucker macht Entwickler glücklich, kleinere Heaps machen die Buchhaltung glücklich. Wer lange in Unternehmen gearbeitet hat, versteht: Ein Grund, der in einen Beschaffungsantrag geschrieben werden kann, ist viel mehr wert als einer, der in eine Pressekonferenz geschrieben werden kann.

Q4: Post-Quanten-Schlüsselaustausch ist in TLS 1.3 eingezogen – etablierte Sprachen planen für die Zeit in zehn Jahren, warum sprechen AI-Unternehmen selten darüber?

Yongliang: Weil die Kunden beider Seiten die Bewertung von „in zehn Jahren“ völlig unterschiedlich vornehmen. Krankenhausdaten müssen jahrzehntelang aufbewahrt werden, die Bedrohung durch „zuerst speichern, später entschlüsseln“ findet heute bereits statt; während der Datenlebenszyklus der meisten AI-Produkte weniger als zwei Jahre beträgt. Bevor das Schloss verrostet, wird das Produkt bereits abgeschaltet.

Was JEP 527 tut, ist, im Handshake von TLS 1.3 gleichzeitig sowohl mit traditionellen Algorithmen als auch mit quantenresistenten Algorithmen jeweils einen Schlüssel zu berechnen, sodass ein Einbruch auf einer der beiden Seiten nicht tödlich ist. Warum muss das jetzt getan werden? Weil Angriffe der Art „zuerst speichern und warten, bis Quantencomputer ausgereift sind, um dann zu entschlüsseln“ heute bereits stattfinden: Angreifer fangen deinen aktuellen verschlüsselten Datenverkehr ab und speichern ihn, um in zehn Jahren das Schloss zu knacken. Die Aufbewahrungsfrist für medizinische Daten wird in Jahrzehnten bemessen. Ein einziger Handshake im heutigen Registrierungssystem kann bedeuten, dass der Geheimtext bis in die 2040er Jahre von rechtlicher Bedeutung ist – für Krankenhäuser ist dies also ein Risiko, für das heute bezahlt werden muss, keine Geschichte aus der Zukunft in zehn Jahren. Der Datenlebenszyklus der meisten AI-Startups hingegen beträgt weniger als zwei Jahre, die Trainingsdatensätze werden alle paar Monate ausgetauscht, und bevor das Schloss des Produktes verrostet, wird es bereits abgeschaltet. Es ist also natürlich, dass niemand in Eile ist, über einen Schlosswechsel zu sprechen. Hier geht es nicht darum, wer besser oder schlechter ist, sondern um unterschiedliche Zeitskalen: Die Nutzer etablierter Sprachen budgetieren für das Jahr 2040, während die Kunden der AI-Branche darauf wetten, ob sie in sechs Monaten überhaupt noch existieren – beide Seiten sind rational und müssen einander nicht verspotten.

Q5: Drei handfeste Ratschläge für alle, die noch im Java-Ökosystem sind

Yongliang: Drei, in dieser Reihenfolge: In der Produktion nur LTS upgraden, Speichereinsparung als ernsthafte Kennzahl behandeln, KI Code schreiben lassen — aber KI keine Architekturentscheidungen überlassen.

Erstens: In der Produktionsumgebung nur LTS upgraden, nicht dem Neuesten hinterherjagen. Java 25 ist das aktuelle LTS; 27 kann man zum Ausprobieren, Lesen und als technisches Radar für das Team nutzen, aber nicht in der Produktion einsetzen; das nächste LTS wird voraussichtlich JDK 29 sein, dann nimmt man die ausgereiften Dinge aus 27 und 29 gemeinsam auf. Die Neuen-Versionen-Angst ist in diesem Ökosystem ein Scheinproblem; das echte Risiko sind Kompatibilitätsunfälle, die durch das Hinterherjagen des Neuesten entstehen. Zweitens: Speichereinsparung als ernsthafte Kennzahl verwalten. Nachdem Compact Object Heads standardmäßig aktiviert sind, eine Woche darauf verwenden, die Heap-Belegung der Kernservices vergleichend zu messen (das ist Schätzungsarbeit, aber die Richtung stimmt), den eingesparten Speicher in Geld umrechnen und in die Quartalszusammenfassung schreiben — dem Chef den Return des JVM-Tunings zu zeigen, ist nützlicher als zehn technische Artikel zu schreiben. Drittens: KI Code schreiben lassen, aber KI keine Architekturentscheidungen treffen lassen. Es gibt immer mehr KI-generierten Code, aber welche Abhängigkeiten man wählt, wie man Services aufteilt, wie die Daten fließen — die Auswirkungen dieser Entscheidungen zählen in Jahren und müssen von Menschen getragen werden. Dass Structured Concurrency nach der 7. Preview noch nicht finalisiert ist, zeigt genau, wie schwer solche Entscheidungen über Nebenläufigkeitsmodelle sind — so schwer, dass sieben öffentliche Überarbeitungsrunden nötig sind, bevor man sich traut, sie final festzulegen. Ich habe siebzehn Jahre Software gemacht, ein Team von siebzig Leuten geleitet, und die teuersten Fehler, die ich gemacht habe, waren alle Architekturentscheidungen nach dem Motto „damals dachte ich, das kann erst mal so gemacht werden” — keine einzige davon war ein Syntaxfehler.

Epilog

Shiwen: Zum Schluss, fassen Sie diese Folge in einem Satz zusammen?

Yongliang: AI bestimmt, wie schnell Code geschrieben wird, die JVM bestimmt, wie stabil das System läuft – in einer Zeit, in der immer schneller geschrieben wird, ist Stabilität selbst ein Wettbewerbsvorteil.

Shiwen: Diesen Satz geben wir allen mit auf den Weg. Bis zur nächsten Folge.

【Technischer Tiefblick】Die Kosten im Objekt-Header, die Sie nie geschrieben haben – wie G1 und der kompakte Objekt-Header gemeinsam sparen

Der rote Faden dieser Ausgabe: „Speicher sparen liegt näher an den echten Schmerzpunkten von Unternehmen als neue Syntax.” Für Leser, die einen Schritt tiefer gehen möchten, wird hier eine weitere Schicht aufgeblättert: Warum zwei unscheinbare Standardeinstellungen es verdienen, die beiden wichtigsten Plätze in JDK 27 einzunehmen.

Erste Schicht: Was der Objekt-Header speichert. In Java trägt jedes Objekt außer den von Ihnen geschriebenen Feldern auch einen Header: das Mark Word speichert Hash-Code, Sperrzustand und GC-Markierungen, dazu ein Zeiger auf die Klassen-Metadaten. Diese Informationen haben Sie nie in einer einzigen Code-Zeile geschrieben, aber jedes Objekt trägt sie mit sich.

Zweite Schicht: Warum diese Kosten erheblich sind. Wenn auf 64-Bit-Maschinen standardmäßig komprimierte Zeiger aktiviert sind, belegt ein Objekt-Header typischerweise 12 Byte – je kleiner das Objekt, desto höher der Anteil des Headers. Ein Objekt, das nur zwei Integers enthält, hat 8 Byte Daten und 12 Byte Header – mehr als die Hälfte des Speichers fließt in das „Gepäck”. Bei Diensten mit Millionen kleinen Objekten (Caches, Sessions, Message Queues sind besonders betroffen) besteht der Großteil des Heaps nicht aus Daten, sondern aus Gepäck.

Dritte Schicht: Wie die beiden JEPs gemeinsam sparen. Der kompakte Objekt-Header (JEP 534, in dieser Version standardmäßig aktiviert) codiert die Header-Informationen neu und komprimiert diesen Anteil deutlich; G1 (JEP 523, wird zum Standard in allen Umgebungen) schneidet den Heap in Region-Stücke, führt die GC nach Pausenzielen durch – Dienste mit großen Heaps müssen sich nicht mehr mit der Wahl des Collectors abmühen. Der eine macht jedes Objekt schlanker, der andere macht die gesamte Heap-Verwaltung reibungsloser.

Zurück zum roten Faden dieser Ausgabe: Neue Syntax löst die Frage, ob das Programmieren „angenehm” ist; Objekt-Header und Collector lösen die Frage, ob die „Rechnung schmerzt”. Für Unternehmen liegt der Schmerz nie auf der Tastatur.

Informationsquellen dieser Ausgabe

OpenJDK-announce-Mailingliste 2026-09-15: Mark Reinhold „JDK 27 General Availability” (Build 35, mit Liste von 9 JEPs)
jdk.java.net/27 (GPLv2-lizenzierter OpenJDK-Build-Download)
OpenJDK-Halbjahresveröffentlichungsrhythmus und LTS-Namenskonvention (Stand 2026-09-16, das nächste LTS wird voraussichtlich JDK 29)