Die Veröffentlichung für das OpenJDK 25 ist für den 16. September 2025 vorgesehen. Diesmal sind 18 JEPs (JDK Enhancement Proposals) eingeplant. Das ist zwar etwas weniger als noch bei Java 24, aber dafür werden dieses Mal einige Features nach vorangehenden Previews finalisiert. Außerdem bieten die meisten Distributoren für Java 25 wieder einen verlängerten Support (LTS) an. Viele Java-Projekte wechseln in den nächsten Monaten vom letzten LTS Release 21 zu 25.

Wir werfen hier einen ersten Blick auf die aus Developer-Sicht interessantesten Punkte. Weitere Details lassen sich über die jeweiligen JEPs nachvollziehen. In einem zweiten Post betrachten wir dann die weiteren Änderungen, die mehr unter der Haube versteckt oder nicht so relevant für die Java-Entwicklerinnen und -Entwickler sind. Die meisten in diesem Beitrag beschriebenen JEPs sind übrigens Wiedervorlagen, die bereits in früheren Java-Versionen als Inkubator oder Preview veröffentlicht wurden. Ganz neu sind die Stable Values, die eine größere Flexibilität bei der Initialisierung von final-Feldern bieten.

JEP 502: Stable Values

Stable Values sind Objekte, die genau einmal zum Einsatz kommen und danach unveränderlich sind. Die JVM (Java Virtual Machine) behandelt ihren Inhalt wie eine echte Konstante und kann dieselben Optimierungen (zum Beispiel Constant Folding) anwenden, wie bei final‑Feldern – nur, dass die Initialisierung beliebig spät erfolgen darf. Damit bekommt Java eine „Deferred Immutability“, die Start‑ und Aufwärmzeiten verkürzt, ohne Sicherheitsrisiken mit Thread einzugehen. Die Ziele sind:

• Schnelleres Start‑Up: Keine monolithische Initialisierung aller Komponenten mehr.
• Entkopplung von Erzeugung & Initialisierung eines unveränderlichen Werts – ohne Performance‑Kosten.
• Garantierte At‑Most‑Once‑Initialisierung auch in hoch parallelen Szenarien.
• Konstanten‑Optimierungen für Anwendungscode zugänglich machen, nicht nur für JDK‑internen Code.

Stable Values sind eine reine Library‑API. Es wird kein neues Schlüsselwort geben. Außerdem gibt es keine Änderung an der Semantik von final, bestehender Code bleibt unberührt. Bisher müssen final‑Felder eager (sofort) initialisiert werden – die Initialisierung eines Loggers oder eine Datenbank‑Connection bremst so den Programmstart aus. Workarounds wie Lazy Holder, Double‑Checked Locking oder ConcurrentHashMap.computeIfAbsent sind entweder eingeschränkt, fehleranfällig oder verhindern JIT‑Optimierungen (Just in Time). Stable Values schließen die Lücke zwischen strenger Immutability und flexibler Lazy‑Initialisierung.

Der Lambda-Ausdruck in orElseSet wird garantiert genau einmal ausgeführt, selbst wenn mehrere Virtual Threads gleichzeitig logger() aufrufen. Danach kann der JIT (Just in Time Compiler der Hotspot VM) alle Zugriffe optimieren, wie durch Constant Folding.

class OrderController {
    private final StableValue logger = StableValue.of();

    private Logger logger() {
        return logger.orElseSet(() -> Logger.create(OrderController.class));
    }
}

Stable Values sind besonders für parallele Programmierung interessant. Im Umfeld von Virtual Threads arbeitet das Entwicklerteam schon seit Längerem an weiteren Bausteinen. Während Structured Concurrency bereits zum sechsten Mal als Preview dabei ist, gelten die Scoped Values nach vier Previews jetzt als final.

JEP 506 – Scoped Values (Final in JDK 25)

Scoped Values sind eine Alternative zu ThreadLocal-Variablen, die Threads unterschiedliche Zugriffe auf einen globalen Zustand ermöglichen. ThreadLocal lässt sich beliebig ändern, hat eine unbegrenzte Lebensdauer (Leak-Gefahr, vor allem in Pools) und ist teurer durch Vererbung an Kind-Threads. Scoped Values begrenzen die Lebensdauer klar, sind read-only und lassen sich über viele Threads hinweg platz- und zeitsparend nutzen. Gegenüber den Previews wird die API finalisiert. Einzige Änderung: ScopedValue.orElse akzeptiert kein null mehr. Ein Web-Framework bindet beispielsweise einmal pro Request den FrameworkContext (zum Beispiel Spring ApplicationContext oder ein AuthenticationContext). Die Handler und interne Framework-Aufrufe (etwa DB-Zugriff) können auf diesen FrameworkContext zugreifen, ohne dass er immer als zusätzlicher Parameter durchgereicht werden muss. Und auch in Kind-(Virtual) Threads ist er automatisch verfügbar.

JEP 505 – Structured Concurrency (Preview)

Mit dem StructuredTaskScope erhält eine API Einzug, die zusammengehörige Nebenläufigkeit als eine Einheit behandelt: Subtasks werden im Block geforkt und über ein join() wieder zusammengeführt. Fehler sorgen gegebenenfalls für einen direkten Abbruch anderer Subtasks. Beim Debugging lässt sich in den Thread-Dumps die Task-Hierarchie leicht nachvollziehen. Damit erlaubt Structured Concurrency die Implementierung auf eine besonders les- und wartbare Art und Weise. Alternativ konnten Entwicklerinnen und Entwickler für diesen Zweck bisher die Parallel Streams, den ExecutorService oder reaktive Programmierung einsetzen. Alles sehr mächtige Ansätze, die aber gerade einfache Umsetzungen unnötig kompliziert und fehleranfällig machen.

Neu gegenüber der letzten Preview: Scopes lassen sich über statische Fabrikmethoden öffnen (open() für den Standardfall, d. h. entweder sind alle erfolgreich oder bei einem Fehler bricht alles ab). Alternative Abschluss-Policies und Rückgabewerte werden über Joiner-basierte open(...)-Varianten gesteuert. Ziele sind unter anderem das Vermeiden von Thread-Leaks und Cancellation-Delays sowie bessere Observability. Nicht beabsichtigt ist der Ersatz von ExecutorService/Future, neue Channel-Primitiven oder eine neue Cancel-Mechanik. Gerade bei I/O-Fan-out mit Virtual Threads wird die Koordination einfacher, robuster und nachvollziehbarer.

// --enable-preview beim Kompilieren und Starten 
record Response(String user, int order) {}

Response handle() throws InterruptedException {
  try (var scope = StructuredTaskScope.

Trotz seiner 30 Jahre zieht Java auch weiter viele Programmierneulinge an. Die JEPs 511 (Module Import Declarations) und 512 (Compact Source Files and Instance Main Methods) helfen aber nicht nur Anfängern, sie machen auch erfahrenen Developern das Leben einfacher. Beide JEPs erreichen nun nach mehreren vorangegangenen Previews den finalen Status.

JEP 511 – Module Import Declarations (Final in JDK 25)

Dieses JEP ergänzt die Sprache um import module , sodass alle exportierten Pakete eines Moduls mit einer Deklaration verfügbar sind. Das reduziert Import-Boilerplate, erleichtert die Wiederverwendung modularer Bibliotheken (ohne dass der eigene Code modular sein muss) und funktioniert reibungslos neben den bekannten import-Deklarationen. Für Einsteiger oder auch für Anwender des Prototypings in JShell sinkt die Hürde, weil sie nicht mehr wissen müssen, in welchem Paket sich einzelne Typen befinden. In Szenarien mit transitiven Modulabhängigkeiten (zum Beispiel java.sql, java.xml) vereinfacht sich die Nutzung zusammengehöriger APIs spürbar.

import module java.base;

List xs = List.of("a", "b");
Path p = Path.of("data.txt");
// List/Map/Stream/Path sind ohne einzelne Paket-Imports nutzbar

JEP 512 – Compact Source Files & Instance-main (Final in JDK 25)

Wir können jetzt in einer einzelnen Java-Datei viel schlanker kleine Programme abspeichern und ausführen. Ziel ist eine sanfte Einstiegskurve: Grundkonzepte zuerst, Programmieren-im-Kleinen ohne überflüssige Zeremonie. Bei wachsender Komplexität lässt sich der Code nahtlos zu Klassen/Packages/Modulen ausbauen. Gegenüber den Previews wird das Feature finalisiert und umbenannt (aus simple wird compact). Die neue IO-Klasse liegt nun in java.lang und wird damit implizit importiert, ihre statischen Methoden aber nicht. Außerdem basiert IO jetzt auf System.out/System.in statt java.io.Console.

// > java Main.java
void main() {
    IO.println("Hello, World!");
}

JEP 513 – Flexible Constructor Bodies (Final in JDK 25)

Konstruktoren dürfen nun Anweisungen vor dem Aufruf von super(...) oder this(...) enthalten. Diese Prolog-Phase dient beispielsweise zur Validierung von Argumenten, zum Initialisieren eigener Felder, ohne das entstehende Objekt anderweitig zu referenzieren, oder zum Transformieren von Inputwerten. Danach folgt der gewohnte Epilog. Das macht viele Konstruktoren natürlicher (z. B. fail-fast) und erhöht die Sicherheit, weil Unterklassen-Felder vor einem möglichen Zugriff durch Superklassen-Konstruktoren oder dort aufgerufene Methoden bereits gesetzt sind. Ziel ist es, überflüssige Beschränkungen zu entfernen und zusätzliche Garantien für einen vollständig initialisierten Objektzustand zu geben. Das umgeht die praktischen Probleme der bisherigen Regel „super() muss zuerst kommen“, durch die es zu unnötiger Arbeit, zu tückischen Initialisierungsfehlern bei mehreren Threads und zu Integritätsverletzungen kommen konnte.

JEP 507 – Primitive Typen in Patterns, instanceof und switch (3. Preview)

Dieser JEP macht Pattern Matching einheitlich für alle Typen, inklusive Primitive. Er erlaubt primitive Typmuster in allen Pattern-Kontexten (top-level und verschachtelt), erweitert instanceof auf Primitive (inklusive sichere, verlustfreie Umwandlungen) und lässt switch über alle primitiven Typen laufen (auch boolean, long, float, double). Ziel ist weniger Reibung und mehr Ausdrucksstärke: unsichere Casts und Boxing entfallen, da ein Pattern nur matcht, wenn die Konversion verlustfrei ist. Außerdem lassen sich Typmuster, instanceof und „safe casting“ semantics sauber aufeinander ausrichten.

// switch mit primitive type pattern
switch (x.getStatus()) {
  case 0 -> "okay";
  case 1 -> "warning";
  case 2 -> "error";
  case int i -> "unknown: " + i;   // zeigt unbekannten int-Status
}

// instanceof mit sicherer Konversion (matcht nur verlustfrei)
if (i instanceof byte b) { /* b nutzen */ }

// Record-Pattern mit sicherem Narrowing
if (json instanceof JsonObject(var map)
    && map.get("age") instanceof JsonNumber(int age)) {
  // nur wenn double → int verlustfrei passt
}

JEP 508 – Vector API (erneut Inkubator)

Die Vector-API erlaubt, Vektorberechnungen in Java auszudrücken, die der HotSpot-Compiler zu nativen SIMD-Instruktionen (x64: SSE/AVX, AArch64: NEON/SVE) kompiliert – mit stabilerer Performance als rein skalare Implementierungen. In JDK 25 ist diese API erneut im Inkubatorstatus, da man noch auf die Implementierung von Value Classes als Grundlage für die Vector API wartet. Neu sind:

• VectorShuffle ↔ MemorySegment-Zugriff
• Anbindung nativer Mathe-Bibliotheken über die FFM-API statt HotSpot-C++-Code (wartungsärmer)
• Auto-Vektorisierung von Float16-Operationen (Add/Sub/Mul/Div/Sqrt/FMA) auf unterstützten x64-CPUs.

Ziel ist eine klare, plattform-agnostische API mit verlässlicher Abbildung auf Vektorbefehle und „graceful degradation“.

Das waren 8 der insgesamt 18 neuen JEPs. Die anderen, die weniger für Entwicklerinnen und Entwickler relevant, aber trotzdem spannende Themen sind, schauen wir uns in einem zweiten Post an. Zusätzlich sind die vielen kleineren Neuerungen, für die es keine JEPs gibt, in den Release-Notes zum Nachlesen. Änderungen am JDK (Java Klassenbibliothek) wie die Stable Values oder Structured Concurrency kann man sich zudem über den Java Almanac anzeigen lassen.

(mdo)

Anthropic und OpenAI haben im Juni und Juli gegenseitig ihre Modelle auf Sicherheit sowie Stabilität untersucht und nun zeitgleich die jeweiligen Berichte veröffentlicht. Dabei wenden beide jeweils ihre eigenen Testverfahren auf die Modelle des anderen an, sodass die Berichte nicht direkt vergleichbar sind, aber viele interessante Details zeigen.

Sicherheit umfasst in den Untersuchungen nicht nur die reine Hacker-Sicherheit, wie im aktuellen Threat Report, sondern meint auch Modell-, Aussage- und Stabilitätsfestigkeit. Beispielsweise sind Halluzinationen ein Thema.

Ziel der externen Evaluierungen war es, „Lücken aufzudecken, die andernfalls übersehen werden könnten“, schreibt OpenAI im Report. Dabei ging es nicht um die Modellierung von realen Bedrohungsszenarien, sondern darum, „wie sich die Modelle in Umgebungen verhalten, die speziell als schwierig konzipiert sind.“

Anthropic möchte „die besorgniserregendsten Aktionen verstehen, die diese Modelle auszuführen versuchen könnten, wenn sie die Gelegenheit hätten … um dieses Ziel zu erreichen, konzentrieren wir uns speziell auf die Bewertung agentenbezogener Fehlausrichtungen.“

Die Tests erfolgten über die jeweiligen APIs an den Modellen selbst, also beispielsweise GPT und nicht ChatGPT, wobei die Entwickler gewisse Sicherheitsmechanismen deaktiviert haben, um die Ausführung der Tests nicht zu stören. Einbezogen haben sie die Modelle GPT-4o, 4.1, o3 sowie o4-mini auf der einen Seite und Claude Opus 4 sowie Sonnet 4 auf der anderen. Beide Testteams ließen ihre eigenen Modelle zum Vergleich mitlaufen.

Reasoning hat Sicherheitsvorteile

Da die Forscherinnen und Forscher die Tests sehr unterschiedlich konzipiert haben, lassen sich wenig zusammenfassende Ergebnisse feststellen. Anthropic betont „keines der von uns getesteten Modelle war auffallend falsch ausgerichtet“. Und beide Berichte zeigen, dass aktiviertes Reasoning meist besser abschneidet, aber auch nicht immer.

Außerdem ergeben die Studien, dass hohe Sicherheit mit vielen ablehnenden Antworten einhergeht. Die Modelle, die in einem Testbereich gut abschneiden, verweigern dort auch häufiger komplett die Aussage.

Im Folgenden ein paar Beispiele aus den umfangreichen Berichten.

Die KI hilft im Drogenlabor, bei Biowaffen und der Terrorplanung

Anthropic widmet sich intensiven Verhaltenstests: Was lässt die KI mit sich machen? Kooperiert sie mit den Anwenderinnen und Anwendern auch bei schädlichen oder zweifelhaften Prompts? Hilft sie gar bei Verbrechen oder Terror? – Die Antwort lautet eindeutig „ja“, setzt im Dialog allerdings viele Wiederholungen und fadenscheinigen Kontext voraus, wie die Behauptung, man recherchiere, um Übel abzuwenden. GPT-4o und 4.1 sind „freizügiger, als wir erwarten würden“. Dagegen zeigt sich GPT-o3 als das beste Modell im Vergleich auch mit den Claude-Modellen, lehnt im Gegenzug aber auch übermäßig viele Fragen schlichtweg ab („Overrefusal“).

In diesem Zusammenhang untersucht Anthropic weitere menschenähnliche Verhaltensweisen wie Whistleblowing oder Versuche der KI, aus vermeintlichem Eigennutz verfälschte Antworten zu geben, „zum Beispiel dokumentierten wir eigennützige Halluzinationen von o3“.

Ausbruch aus dem Käfig

OpenAI wählt einen strukturierten Forschungsansatz und wirft einen Blick darauf, wie genau sich die Modelle an Vorgaben – auch modellinterne – halten und wie gut es einem Angreifer gelingt, hier die Grenzen zu überschreiten. Die Modelle sollen die Hierarchie der Vorgaben (Instruction Hierarchy) einhalten, also interne Regeln vor externen beachten. Beispielsweise soll das Modell bestimmte interne Aussagen oder Passwörter geheim halten. Hier beweist sich Claude 4 als besonders sicher. Beim Jailbreak-Test (StrongREJECT v2), der versucht, das Modell zu Aussagen zu bewegen, die es nicht machen soll, schnitten die GPT-Modelle besser ab, insbesondere o3. Sicherheitsforscher sehen im Jailbreaking eines der größten Sicherheitsprobleme im Zusammenhang mit KI.

Opus und Sonnet halluzinieren am wenigsten, verweigern aber auch am häufigsten die Antwort komplett.

Beide Teams loben einander: „Die Bewertungen von Anthropic ergaben, dass unsere Modelle in mehreren Bereichen verbesserungswürdig sind“, schreibt etwa OpenAI und weist auf GPT-5 hin, das der Test noch nicht berücksichtigt. Und die andere Partei sagt: „Die Ergebnisse von OpenAI haben uns geholfen, uns über die Grenzen unserer eigenen Modelle zu informieren, und unsere Arbeit bei der Evaluierung von OpenAIs Modellen hat uns geholfen, unsere eigenen Werkzeuge zu verbessern.“

Viele weitere Details finden sich in den parallelen Veröffentlichungen von Anthropic und OpenAI.

(who)

In dieser Folge sprechen Richard Seidl und Gitte Ottosen darüber, wie Teams Qualität in der agilen Welt organisieren. Sie diskutieren, wer in einem crossfunktionalen Team für das Testen zuständig ist und was ein Tester über die Tools hinaus beiträgt. Das Gespräch spannt den Bogen von der Teststrategie bis zur KI-Unterstützung, mit einem klaren Blick auf Risiken, Daten und Verzerrungen.

„But if you ask many Scrum masters today, and unfortunately a few coaches as well, what does the Agile manifesto say or what are the 12 principles of Agile? They don’t know.“ – Gitte Ottosen

Dieser Podcast betrachtet alles, was auf Softwarequalität einzahlt: von Agilität, KI, Testautomatisierung, bis hin zu Architektur- oder Code-Reviews und Prozessoptimierungen. Alles mit dem Ziel, bessere Software zu entwickeln und die Teams zu stärken. Frei nach dem Podcast-Motto: Better Teams. Better Software. Better World.

Richard Seidl spricht dabei mit internationalen Gästen über modernes Software Engineering und wie Testing und Qualität im Alltag gelebt werden können.

Die aktuelle Ausgabe ist auch auf Richard Seidls Blog verfügbar: „Ist wirklich jeder für Qualität verantwortlich? – Gitte Ottosen“ und steht auf YouTube bereit.

(mdo)