© Enkel/Shutterstock.com
Diese JEPs sind Teil des JDK 16

Java 16


JEP 338 – Vector API (Incubator)

338.tif_fmt1.jpg

Das dienstälteste JEP, das in JDK 16 enthalten sein wird, ist JEP 338 – Vector API (Incubator). Für Java 16 soll damit die erste Iteration eines neuen Inkubatormoduls implementiert werden: jdk.incubator.vector. Das API ist darauf ausgelegt, eine ganze Reihe von Vektorberechnungen klar und prägnant auszudrücken, die ihrerseits aus Vektoroperationen bestehen, wie sie bspw. in Schleifen oder auch im Control Flow vorkommen. Ablaufen soll das Ganze zuverlässig zur Laufzeit, egal, welche Architektur zugrunde liegt: Die Unterstützung für Laufzeitimplementierungen soll für unterschiedlichste CPU-Architekturen verfügbar werden, die mit vektorbezogenen Hardwareanweisungen umgehen können.

Zukünftig soll ein Vektor von der abstrakten Klasse Vector<E> repräsentiert werden. Die Typvariable E entspricht dem sogenannten Boxed Type der primitiven skalaren Integral- oder Floating-Point-Elementtypen, die vom Vektor abgedeckt werden. Überdies haben Vektoren dann einen Shape, der die Größe (in Bits) des Vektors definiert.

JEP 347 – Enable C++14 Language Features

347.tif_fmt1.jpg

Auch im JDK wird C++-Code verwendet, das ist kein Geheimnis. Allerdings wird es wohl ein Rätsel bleiben, warum bis einschließlich JDK 15 lediglich die Sprachfunktionen aus C++98/03 verfügbar waren und sind. Mit JDK 11 konnte man seine Programme bereits mit aktuelleren Versionen des C++-Standards erstellen, allerdings werden bis dato keine neuen Sprachfeatures unterstützt. JEP 347 sieht vor, einen Frühjahrsputz zu veranstalten und endlich Sprachfeatures neuerer Versionen bis einschließlich C++14 verfügbar zu machen. In diesem Zusammenhang werden auch bestimmte Anleitungen bereitgestellt, welche dieser Features im HotSpot-Code verwendet werden können und wie. Außerhalb des Codes für HotSpot ist ein anderes JEP nötig, JEP 347 bezieht sich explizit auf diesen.

Eine Übersicht über sämtliche neue Features gibt es in der Beschreibung des JEP. Zu den neu verfügbaren Funktionen gehören unter anderem variadische Templates, stark typisierte Enums, delegierende Konstruktoren und explizite Konversionsoperatoren. Nicht vorgesehen sind neue String- oder Symbolliterale, Namespaces oder nutzerdefinierte Literale.

JEP 357: Migrate from Mercurial to Git

357.tif_fmt1.jpg

Was lange währt, wird endlich gut. Bereits Mitte 2019 wurde durch Projekt Skara das Ende des Hostings von Java auf Mercurial eingeläutet. Wenig überraschend war dann auch das finale Ergebnis, das einen Umzug bzw. die Migration auf das Versionskontrollsystem Git vorsah. Mit Java 16 soll dies nun wie geplant umgesetzt werden, doch ist das ohnehin nur eine Formalität. Die Umzugsarbeiten auf das neue Source-Code-Management-System sind seit 2020 im Gange und nun pünktlich zur Veröffentlichung von Java 16 abgeschlossen worden.

JEP 369: Migrate to GitHub

369.tif_fmt1.jpg

Auch JEP 369 ist, wie das Bruder- oder Schwester-JEP-357, eigentlich eine reine Formsache: Die Migration auf GitHub als Hostingplattform wurde ebenfalls in Projekt Skara beschlossen, und wie bei dem SCM-System entschied man sich für die populärste und bekannteste Hostingplattform für die Repositories der OpenJDK-Community. Hierbei sei erwähnt, dass weder der Issue Tracker, das Wiki oder irgendeine andere Form der bestehenden Infrastruktur durch diese Änderungen beeinflusst werden – jedenfalls ist das nicht Teil von JEP 369 und (noch) nicht geplant. Der Umzug hat das Ziel, schnelleres Klonen und Pullen zu ermöglichen, die Performance von Git und GitHub ist signifikant besser als die der bisher genutzten SCM-Lösung.

JEP 376: ZGC – Concurrent Thread-Stack Processing

376.tif_fmt1.jpg

Die Garbage Collection sorgte in der Vergangenheit bei Oracles Virtual Machine HotSpot für Pausen und Probleme mit der Skalierung. Daher wurde bei Oracle beschlossen, sämtliche Tasks im Zuge der Garbage Collection aus den sogenannten Safepoints herauszunehmen. Diese Safepoints stellen so etwas wie einen Freeze beim Ausführen eines Programms dar, bei dem garantiert werden kann, dass der Heap konsistent ist. Alles steht also für einen Moment still, erst dann kann die Garbage Collection beginnen – das ist natürlich ungünstig.

Dank JEP 376 läuft die Garbage Collection nun ab JDK 16 endlich komplett parallel zum Programmfluss. Damit ist die Eliminierung der GC-Pausen in den Safepoints vollbracht. Bereits zuvor wurden etwa Marking, Relocation, Reference Processing, Class Unloading und das Root Processing ausgebaut – somit kann der ZGC endlich komplett parallel laufen.

Das Stack Processing wurde zudem lazy, kooperativ, nebenläufig und inkrementell gemacht. Auch die anderen Root Processings wurden aus den ZGC Safepoints entfernt, die pro Thread anfallen. Was mit JEP 376 nicht verfolgt wird, ist die Implementierung nebenläufiger Pro-Thread Processings von Safepoint-Operationen, die nichts mit der Garbage Collection zu tun haben, also etwa die Neudefinierung von Klassen.

JEP 380: Unix-Domain Socket Channels

380.tif_fmt1.jpg

TCP/IP ist schön und gut, aber effektiver und vor allem sicherer läuft die Interprozesskommunikation (IPC) via Unix-Domain-Sockets. Damit auch Java-Entwickler von den umfangreichen Funktion...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang