Java 19 verbessert die Nebenläufigkeit mit virtuellen Threads aus Project Loom
Die Programmiersprache bringt im aktuellen Release zwei wichtige Vorstöße aus Project Loom als Preview-Features mit: Virtual Threads und Structured Concurrency.
Im planmäßigen Sechsmonatstakt ist Java 19 erschienen. Das Release bringt insgesamt sieben Neuerungen in Java Enhancement Proposals (JEPs) mit, von denen je zwei aus den Projekten Loom, Amber und Panama stammen. Sie zielen auf nebenläufige Programmierung, Produktivität und die Anbindung an nicht-Java-APIs.
Abseits der Projekte bringt Java 19 mit dem JEP 422: Linux/RISC-V Port eine Umsetzung für die RISC-V-Architektur. Sie ist zum Start auf die RV64GV-Konfiguration beschränkt, soll aber auch für weitere Konfigurationen erfolgen.
Virtuelle Fäden auf dem Webstuhl
Project Loom zielt auf eine verbesserte und schlankere Nebenläufigkeit für Java-Programme. Loom bedeutet Webstuhl, also das Werkzeug, um die Fäden (Threads) zu einem großen Ganzen zusammenzufügen. Java 19 webt zwei JEPs aus Project Loom als neue Preview-Features ein: Virtual Threads und Structured Concurrency.
Das JEP 425 Virtual Threads bezeichnet ein in Java neues Konzept für nebenläufige Anwendungen. Die virtuellen Threads ergänzen die bisher verwendete Umsetzung über Plattform-Threads, die Java direkt auf Betriebssystems-Threads ausführt. Virtuelle Threads nutzen Carrier Threads als zusätzliche Ebene. Wenn ein virtueller Thread bei einer blockierenden Operation stoppt, kann die Runtime einen anderen auf den Carrier Thread legen, sodass der Plattform-Thread weiterarbeitet.
Das Verteilen und Pooling der einzelnen Threads obliegt somit nicht mehr den Entwicklerinnen und Entwicklern, sondern der Laufzeitumgebung. Die Umsetzung in Project Loom soll explizit nicht die traditionelle Implementierung der Plattform-Threads ersetzen, sondern ergänzen. Auch will sie kein neues Concurrency-Modell einführen.
Strukturierte Aufgabenverteilung
Ebenfalls zu Project Loom gehört das JEP 428 Structured Concurrency. Dabei geht es darum, Tasks aus unterschiedlichen Threads in einer Einheit zu verwalten, um die Wartbarkeit und Zuverlässigkeit von nebenläufigem Code zu verbessern. Das Konzept ist wie auch das der virtuellen Threads allgemein nicht neu, und diverse Sprachen und Frameworks bieten unterschiedliche Ansätze für die strukturierte Nebenläufigkeit.
Java 19 fĂĽhrt die Klasse StructuredTaskScope
ein, mit der man einen Task als Gruppe nebenläufiger Subtasks anlegt und als geschlossene Einheit verwaltet. Die API kennt unter anderem die Vorgabe ShutdownOnFailure
, die dafĂĽr sorgt, dass beim Auftreten eines Fehlers in einem Subtask die anderen entsprechend gestoppt werden. Analog dazu gibt ShutdownOnSuccess
vor, dass alle Subtasks ihre Arbeit beenden, wenn einer erfolgreich durchgelaufen ist.
Project Amber und das Pattern Matching
Die zwei Neuerungen im Project Amber beziehen sich auf Pattern Matching. Das Projekt kümmert sich um kleinere Sprachfeatures, die der besseren Produktivität dienen sollen. Das JEP 427 Pattern Matching for switch trägt bereits die Kennzeichnung Third Preview. Es erweitert das in Java 17 unter JEP 406 erstmals eingeführte und in Java 18 als JEP 420 fortgeführte Pattern Matching für Switch Statements und Expressions. Letztere waren als JEP 361 ebenso Bestandteil von Java 14 wie das grundsätzliche Pattern Matching als JEP 305.
JEP 405: Record Patterns ist die erste Preview zum Dekonstruieren der Werte in Records. Letzteres Konstrukt zum Speichern simpler Werte in Form von Immutable Data waren in Java 14 und 15 als Preview vorhanden, bevor sie in Java 16 zum Standard wurden. Das Konzept erlaubt das Verschachteln von Patterns wie in folgendem Beispiel aus dem JEP:
record Point(int x, int y) {}
enum Color { RED, GREEN, BLUE }
record ColoredPoint(Point p, Color c) {}
record Rectangle(ColoredPoint upperLeft,
ColoredPoint lowerRight) {}
static void printColorOfUpperLeftPoint(Rectangle r) {
if (r instanceof Rectangle(ColoredPoint(Point p,
Color c),
ColoredPoint lr)) {
System.out.println(c);
}
}
Oh, wie schön ist Panama
Project Panama zielt auf die Anbindung von Java-Programmen an nicht-Java- beziehungsweise JVM-Komponenten wie C-basierten Libraries und Interfaces. JEP 424 Foreign Function & Memory API hat im JDK 19 Preview-Status. Die unter dem Akronym FFM geführte API soll eine einheitliche Schnittstelle zu Code und Daten jenseits der Java-Runtime bieten. Sie kombiniert die bisherigen Vorstöße JEP 389 Foreign Linker API aus Java 16 und die in Java 14 als JEP 370 gestartete Foreign-Memory Access API.
Ziel ist es, das Java Native Interface (JNI) mit einer eleganteren Umsetzung abzulösen. Dabei stehen unter anderem auch Sicherheitsaspekte im Fokus: Die API erlaubt zwar das Ausführen externer Operationen, deren Speichersicherheit nicht gewährleistet ist, warnt dabei aber vor dem Risiko von Speicherfehlern.
Das JEP 426 Vector API befindet sich noch im Inkubator, also vor der Previewphase. Allerdings gab es den ersten Aufschlag dazu bereits als JEP 338 in Java 16. Die API soll eine Schnittstelle für Vektorrechnung auf CPU-Ebene bringen. Zu den Neuerungen im jüngsten JEP gehört die Anbindung an die FFM-API, um Vektoren in MemorySegment
-Instanzen abzulegen oder daraus zu laden.
Oracles Bekenntnis zu Java
Auf dem virtuellen Pressetermin zum Release vom JDK 19 betonte Georges Saab, Senior Vice President fĂĽr Entwicklung der Java Platform Group und Vorsitzender des OpenJDK-Verwaltungsrates bei Oracle, das Bekenntnis seines Unternehmens zu Java. Oracle sei nach wie vor der wichtigste Contributor fĂĽr das JDK. Als Beispiel zeigte er ein Diagramm der behobenen Issues im JDK 19.
Daneben nannte er ein paar Zahlen rund um Java, nach denen es 10 Millionen Java-Entwicklerinnen und -Entwickler gibt, die insgesamt 1,8 Millionen Fragen auf StackOverflow gestellt haben. Weltweit existieren laut Saab gut 360 Java User Groups und 355 Java Champions. Seit Kurzem gibt es zudem eine Million zertifizierte Java Developer.
Weitere Informationen zu Java 19 lassen sich dem Oracle-Blog entnehmen. Eine Übersicht zu den neuen JEPs findet sich in den Release Notes zum JDK 19. Die OpenJDK-Variante lässt sich von der JDK-Site herunterladen.
(rme)