Das sind die Neuerungen von Java 12

Oracle hat mit Java 12 planmäßig ein neue Release der Programmiersprache freigegeben. Die offizielle Ankündigung erfolgte auf der JavaLand-Konferenz im Phantasialand bei Brühl, wo dieser Tage knapp 2100 Entwickler zusammengekommen sind, die sich über aktuelle Entwicklungen aus dem Java-Umfeld informieren wollen.

Seit Java 10 erscheint die Programmiersprache im halbjährlichen Turnus. So verwundert es nicht, dass Oracle nun nach Java 11 im September 2018 mit Java 12 ein neues Release freigegeben hat. Die Neuerungen im JDK 12 (Java Development Kit) sind infolge des offenen Entwicklungsprozesses schon geraume Zeit bekannt, im Gegensatz zu früheren Releases hat es dieses Mal auch keine Showstopper etwa durch Sicherheitslücken oder Verzögerungen wie bei der Entwicklung eines Modulsystems wie bei Java 9 gegeben. Letztlich handelt es sich um acht größere Neuerungen, die in unterschiedlichen JEPs (JDK Enhancement Proposals) beschrieben sind.

Die Änderungen kurz und knapp vorgestellt

Oft ist hier an erster Stelle von den Switch Expressions (JEP 325) die Rede, die es zum Beispiel auch in Apples Programmiersprache Swift gibt. Hierbei geht es um eine Erweiterung des switch-Statements, die noch Preview-Status hat und Entwickler entweder als Statement (Anweisung) oder als Expression (Ausdruck) verwenden können. Sie hat im Vergleich zum Statement außerdem einen Rückgabewert. Das JEP soll letztlich auf das Pattern Matching (JEP 305) vorbereiten, bei dem das bisherige switch-Statement zu einigen Unregelmäßigkeiten führen kann.

Ebenfalls neu ist eine Microbenchmark-Suite (JEP 230), mit der Entwickler wohl einfach leicht bestehende Mikrobenchmarks ausführen und neue erstellen können. Sie basiert auf dem bisher nicht integrierten Java Microbenchmark Harness (JMH). Die neue JVM Contants API (JEP 334) wiederum ist zur Modellierung nominaler Beschreibungen von Key-Class- und Laufzeit-Artefakten gedacht, und hier insbesondere von Constants, die aus dem Constant Pool, den jede Java-Klasse besitzt, durch ihren Aufruf während der Laufzeit geladen werden.

Weiterhin gibt es noch den JEP 340 (One AArch64 Port, Not Two), durch den alle Sourcen beseitigt wurden, die mit dem arm64-Port zu tun haben. Den 32- und den 64-Bit-ARM-Port gibt es aber weiter. Ziel ist es hier, zwei 64-Bit-Implementierungen des ARM-Ports zu vermeiden. Der JEP 341 (Default CDS Archives) soll den JDK-Build-Prozesses erweitern, um ein CDS-Archiv (Class Data-Sharing) unter Verwendung der Standardklassenliste auf 64-Bit-Plattformen zu erstellen.

Neues bei der Garbage Collection

Ein weiteres noch als experimentell ausgewiesenes Feature ist der ursprünglich von Red Hat entwickelte Garbage-Collection-Algorithmus Shenandoah (JEP 189), der die Pausenzeiten bei der Garbage Collection reduziert, indem er Evakuierungsarbeiten gleichzeitig mit den laufenden Java-Threads durchführt. Die Pausenzeiten mit Shenandoah sind unabhängig von der Heap-Größe gleich konstant. Shenandoah wird derzeit als Alternative zu bestehenden Algorithmen gesehen.

Die letzten beiden Neuerungen betreffen den Garbage-Collection-Algorithmus G1 – der JEP 344 (Abortable Mixed Collections for G1) und der JEP 346 (Promptly Return Unused Committed Memory from G1). Im ersten Fall wird G1 insofern angepasst, dass Mixed Collections sich künftig abbrechen lassen, wenn sie das Pausenzeitziel potenziell überschreiten. Im zweiten lässt sich der Garbage Collector erweitern, um im Leerlauf automatisch Java-Heap-Speicher an das Betriebssystem zurückzugeben.

Der eine oder andere wird die Raw-String-Literals vermissen, die ursprünglich für Java 12 vorgesehen waren. Dieses Feature, um Strings in ihrer rohen Form zu verwenden, wird aufgrund von Kritik aus der Community erst in einer späteren Java-Version landen.

Das neue Java lässt sich auf der entsprechenden JDK- oder OpenJDK-Webseite herunterladen. Hier bekommt man auch weitere Informationen. (ane)