Java 22 reduziert Boilerplate Code und stabilisiert Anbindung an C++ und Co.

Im turnusmäßigen Sechsmonatstakt ist das OpenJDK 22 erschienen. Das Release kann zwar nicht mit den Neuerungen des Vorgängers mithalten, bringt es aber auf zwölf Java Enhancement Proposals (JEP).

Viele Ergänzungen sind noch als Preview gekennzeichnet. Einige von ihnen knüpfen am OpenJDK 21 an, darunter Structured Concurrency und String Templates, die jeweils in die zweite Preview-Runde gehen. Außerdem gibt es einige neue Vorschaufunktionen wie die Class-File-API und Stream Gatherers.

Der Vorgänger stach allerdings nicht nur wegen insgesamt 15 JEPs hervor, sondern auch, weil viele Anbieter es mit Long Term Support (LTS) veröffentlicht haben.

Fortgeführte Nebenläufigkeit in Project Loom

Ein Bereich, in dem das aktuelle Release an Java 21 anschließt, ist Project Loom, das auf eine verbesserte und schlankere Nebenläufigkeit für Java-Programme zielt. Loom bedeutet Webstuhl, also das Werkzeug, um die Fäden (Threads) zu einem großen Ganzen zusammenzufügen.

Java 21 hatte in dem Bereich die Virtual Threads finalisiert. Ebenfalls im Project Loom sind Structured Concurrency und Scoped Values aufgehängt, die im Vorgänger den Preview-Status erhalten haben und die Java 22 nun als zweite Preview fortführt.

Structured Concurrency hilft dabei, Tasks aus unterschiedlichen Threads in einer Einheit zu verwalten, um die Wartbarkeit und Zuverlässigkeit von nebenläufigem Code zu verbessern. Sie war ursprünglich als JEP 428 in JDK 19 im Inkubator enthalten, in dem sie als JEP 437 in Java 20 blieb. Erst in Java 21 erreichte das Konzept im JEP 453 die Preview-Phase und wechselt nun als "JEP 462: Structured Concurrency" in die zweite Vorschau.

Die im OpenJDK 20 als JEP 429 erstmals eingeführten Scoped Values sind ein Konzept, um unveränderliche Werte innerhalb von und zwischen Threads auszutauschen. Sie sind eine effizientere Alternative zu ThreadLocal-Variablen. Wie diese gelten die Werte prinzipiell nur für den jeweiligen Thread. Der gleiche ScopedValue kann in unterschiedlichen Threads verschiedene Werte annehmen. In dem Zusammenhang handelt es sich bei Scope nicht wie sonst in Java um den lexikalischen Bereich einer Klasse oder Funktion, sondern um einen dynamischen Bereich, den die Laufzeit durch das Binden des Werts vorgibt. Die Scoped Values haben in Java 21 mit dem JEP 446 die Vorschauphase betreten, die sie in Java 22 als "JEP 464: Scoped Values" in der zweiten Preview fortführen.

Mehr Komfort mit Project Amber

Gleich vier der Neuerungen in Java 22 gehören zum Project Amber. In dem "Bernstein"-Projekt finden sich kleinere Sprachfeatures, die vor allem auf eine gesteigerte Produktivität zielen.

String Templates sind gleich ohne Inkubator-Phase mit dem JEP 430 als Preview in Java 21 eingezogen. Sie ergänzen die String-Literale und Textblöcke und ermöglichen die Interpolation von Strings. Damit wird es auch möglich, Template-Prozessoren zu definieren, um beispielsweise JSON-Objekte aus Texten mit Platzhaltern generieren. Die zweite Vorschau "JEP 459 String Templates" für Java 22 bringt nur minimale Anpassungen gegenüber dem ersten JEP mit und dient vor allem dazu, zusätzliches Feedback aus der Community zu sammeln, bevor das Feature endgültig in die Sprache einfließt.

Das ebenfalls als zweite Preview gekennzeichnete "JEP 463: Implicitly Declared Classes and Instance Main Methods" bringt seit dem ersten Entwurf für Java 21 eine leichte Anpassung mit, die unter anderem das Aufrufen der main-Methode vereinfachen soll. Außerdem ändert das Proposal den Namen: Der Vorgänger hieß "JEP 445: Unnamed Classes and Instance Main Methods". Das Ziel ist geblieben: Die main-Methode soll schlanker werden und sich mit weniger Boilerplate-Code umsetzen lassen.

Namenlose Variablen und Patterns dienen ebenfalls dem Vermeiden von Overhead: Wenn Variablendeklarationen oder verschachtelte Patterns syntaktisch erforderlich sind, aber eine Anwendung die Inhalte nicht nutzt, lassen sie sich durch einen einfachen Unterstrich (Underscore _) ersetzen. Das Feature gilt mit dem "JEP 456: Unnamed Variables & Patterns" als fertig, nachdem Java 21 das JEP 443 als Preview eingebracht hatte.

Das neu als Preview eingeführte "JEP 447: Statements before super(...)" erlaubt das Brechen einer alten Regel: Wenn ein Java-Konstruktor den Konstruktor der Oberklasse aufruft, war kein Code vor super erlaubt. Das ändert das Proposal, wobei allerdings kein Code erlaubt ist, der auf die zu erstellende Instanz zugreift. Das stellt sicher, dass das Erstellen des Objekts von oben nach unten erfolgt, also jeweils die Oberklasse vor den Unterklassen initialisiert wird.

Als einen Anwendungsfall für die Neuerung zeigt das Proposal einen Konstruktor, der einen Wert überprüft, bevor er den Konstruktor der Oberklasse aufruft, um bei einem unerlaubten Wert direkt eine Exception zu werfen:

public class PositiveBigInteger extends BigInteger {

  public PositiveBigInteger(long value) {
    if (value <= 0)
      throw new IllegalArgumentException("non-positive value");
    super(value);
  }
}

Kontakt zur Außenwelt mit Project Panama

Project Panama zielt auf die Anbindung von Java-Programmen an nicht-Java- beziehungsweise JVM-Komponenten wie C-basierte Libraries und Interfaces.

Das OpenJDK finalisiert die einheitliche Schnittstelle zu Code und Daten jenseits der Java-Runtime mit dem "JEP 454: Foreign Function & Memory API". Die API ermöglicht den Java-basierten Zugriff auf native Libraries und Daten, "ohne die Zerbrechlichkeit und Gefahren des JNI" (Java Native Interface), wie es im Proposal heißt. Der Vorstoß startete mit der ersten Preview als JEP 424 im JDK 19, die auf den Vorgängern JEP 389 für die Foreign Linker API in Java 16 und die in Java 14 als JEP 370 gestartete Foreign-Memory Access API aufbaute. Nach der zweiten und dritten Preview als JEP 434 in Java 20 und als JEP 442 in Java 21 gilt die API nun als stabil.

Auf dem Weg zum Rekordträger des längsten Inkubator-Status befindet sich die Vector API, die in Java 16 als JEP 338 das erste Mal auftrat und seitdem in allen JDKs weiterentwickelt wurde, aber immer noch keinen Preview-Status hat. Somit ist "JEP 460: Vector API" die siebte Inkubator-Instanz. Das Proposal dient dazu, aktuelle CPU-Architekturen und Befehlserweiterungen wie Single Instruction Multiple Data (SIMD) und Vektorprozessoren für die Vektorberechnung zu nutzen.

Im Kern: Core Libraries & Tools

Von den drei Proposals, die sich auf die Core Libraries und Tools beziehen, sind zwei komplett neu. "JEP 457 Class-File API" führt als erste Preview eine API ein, um Java-class-Dateien zu parsen, zu erstellen und umzuwandeln. Sie soll als Standard für den Core von Java class-Dateien ebenso verarbeiten können wie die Tools von Drittanbietern, darunter ASM oder Apache Commons BCEL (Byte Code Engineering Library). Allerdings soll sie laut der Beschreibung im JEP diese Tools weder ersetzen noch erhebt sie den Anspruch, die schnellste Library zum Verarbeiten von class-Dateien zu werden.

Ebenfalls neu ist das "JEP 461: Stream Gatherers", das die Java Stream-API um zusätzliche Operationen erweitert, die das Transformieren von gestreamten Daten ermöglicht und dabei weitergeht als die bisherige Erweiterung über Stream::collect(). Dieser Collector kann aber weiterhin hinter dem Gatherer stehen, und mehrere Gatherer lassen sich in der Form stream.gather(...).gather(...).collect(...) kombinieren. Die Transformation über die Gatherer kann in 1:1-, 1:n-, n:1- oder n:m-Relation erfolgen.

Community-Konferenz für Java-Entwickler

Die JavaLand-Konferenz findet dieses Jahr vom 9. bis 11. April erstmals am Nürburgring statt. Die Hauptkonferenz der Jubiläumsausgabe bietet rund 140 Vorträge zu den jüngsten und den kommenden Entwicklungen rund um Java und Jakarta EE. Daneben stehen der Einsatz von KI und das Zusammenspiel mit anderen Programmiersprachen auf der Agenda.

Die JavaLand-Veranstaltung ist eine Community-Konferenz für Java-Entwickler und wird durchgeführt von der Deutschen Oracle-Anwendergemeinschaft (DOAG) und Heise Medien in Zusammenarbeit mit dem iJUG, dem Interessenverbund deutschsprachiger Java User Groups.

Das "JEP 458: Launch Multi-File Source-Code Programs" fließt ohne Vorschau in die Sprache ein. Es ergänzt das im OpenJDK 11 eingeführte JEP 330, das es ermöglicht, .java-Sourcedateien direkt auszuführen, ohne sie im Vorfeld separat zu kompilieren. Dabei kompiliert der Launcher die verwendete Klasse ad-hoc in den Speicher. Allerdings funktionierte das bisher nur mit einer einzelnen .java-Datei. Das JEP 458 hebt diese Begrenzung nun auf und ermöglicht auch, verschachtelte Sourcedateien ohne vorheriges Kompilieren zu verwenden.

Weniger Unterbrechung beim Aufräumen

Das letzte Java Enhancement Proposal für Java 22 bezieht sich auf den G1 Garbage Collector. Bisher musste dieser im Zusammenspiel mit Sprachen wie C++ über JNI teilweise pausieren, weil es Funktionen zum Erstellen direkter Pointer auf Java-Objekte gibt, die den Zugriff aus dem nativen Code ermöglichen. Diese Objekte dürfen nicht verschoben werden. Mit dem "JEP 423: Region Pinning for G1" kann der Garbage Collector die Bereiche mit den kritischen Objekten pinnen und somit von den Aufräumarbeiten ausnehmen, dabei aber ansonsten weiterarbeiten.

Neben den JEPs gibt es auch kleinere Ergänzungen wie die Klasse ListFormat, die eine Liste von Strings in drei verschiedenen Stilen und drei verschiedenen Enumerations-Typen sowie passend zur eingestellten Region (Locale) ausgibt. Beispielsweise ergibt eine Aufzählung von Foo, Bar und Baz mit der Locale.US folgende Ausgabe:

Im Deutschen mit der Locale.GERMANY gibt es keine Unterscheidungen zwischen den Stilen FULL, SHORT und NARROW, und auch bei der Art der Aufzählung sticht nur OR hervor:

Sechs Monate

Anders als bei Java 21 gibt es für das JDK 22 keine LTS-Varianten. Damit läuft der offizielle Support üblicherweise so lange, bis Java 23 erscheint, also planmäßig bis September 2024. Für das im September 2023 veröffentlichte Java 21 bietet Oracle dagegen Support für fünf Jahre und erweiterten Support sogar für acht Jahre. Adoptium garantiert für LTS-Releases mindestens vier Jahre Support. Da die Anbieter LTS-Releases im Zweijahresrhythmus herausbringen, wird das für September 2025 vorgesehene Java 25 das nächste Java-Release, für das weitgehender Long-term Support zu erwarten ist.

Die vollständige Liste der Neuerungen lässt sich der OpenJDK-Seite zum JDK 22 entnehmen.

(rme)