JDK 12: Die neuen Funktionen in Java 12

Die Produktionsversion von Java Development Kit 12, basierend auf Java SE (Standard Edition) 12, ist jetzt verfügbar. JDK 12-Builds sind von Oracle für Linux, Windows und MacOS erhältlich. 

Wo kann ich JDK 12 herunterladen?

Sie können das JDK 12 von der Java.net-Website herunterladen.

Open Source Builds werden unter der GNU General Public License v2 mit Classpath Exception bereitgestellt. Kommerzielle Builds von JDK 12 von Oracle finden Sie im Oracle Technology-Netzwerk unter einer Nicht-Open-Source-Lizenz.

Neue Funktionen in Java 12

Shenandoah Müllsammler

Java 12 fügt Shenandoah hinzu, einen experimentellen Garbage-Collection-Algorithmus, um die Pausenzeiten für die Garbage-Collection zu reduzieren, indem Evakuierungsarbeiten gleichzeitig mit der Ausführung von Java-Threads ausgeführt werden. Shenandoah bietet einen geeigneten Algorithmus für Anwendungen, die Reaktionsfähigkeit und vorhersehbare kurze Pausen schätzen. Es ist jedoch nicht beabsichtigt, alle Probleme mit der JVM-Pause zu beheben.

Red Hat unterstützt derzeit Shenandoah auf den Architekturen Aarch64 und AMD64.

Abbruchbare gemischte Sammlungen für den G1-Garbage Collector

Mit Java 12 können gemischte G1-Sammlungen abgebrochen werden, wenn sie das Pausenziel überschreiten. Ein Ziel von G1 war es, ein vom Benutzer angegebenes Pausenzeitziel für seine Erfassungspausen zu erreichen.

Zuvor wählte eine erweiterte Analyse-Engine den Arbeitsaufwand für eine Sammlung aus. Das Ergebnis war eine Reihe von Regionen, die als Sammlungsmenge bekannt sind. Nachdem der Satz ermittelt und die Sammlung gestartet worden war, sammelte G1 alle lebenden Objekte in den Regionen der Sammlungen in allen Regionen, ohne anzuhalten. Dies kann jedoch dazu führen, dass G1 das Pausenzeitziel überschreitet, wenn die Heuristik einer Anwendung einen zu großen Sammlungssatz auswählt.

Es war ein Mechanismus erforderlich, um zu erkennen, wann Heuristiken wiederholt einen falschen Arbeitsaufwand für Sammlungen auswählten, und in diesem Fall G1 die Sammlungsarbeit schrittweise ausführen zu lassen, wobei die Sammlung nach jedem Schritt abgebrochen werden konnte. Der in Java 12 eingeführte Mechanismus ermöglicht es G1, das Pausenzeitziel häufiger zu erreichen.

Sofortige Rückgabe nicht verwendeten festgeschriebenen Speichers

Java 12 erweitert G1, um den Java-Heapspeicher im Leerlauf automatisch an das Betriebssystem zurückzugeben. Dieser Speicher wird in einem angemessenen Zeitraum freigegeben, wenn die Anwendungsaktivität sehr gering ist.

Bisher hat G1 nur bei einer vollständigen Speicherbereinigung oder während eines gleichzeitigen Zyklus Speicher vom Heap zurückgegeben. Wenn G1 versucht, eine vollständige Speicherbereinigung zu vermeiden und nur einen gleichzeitigen Zyklus basierend auf der Heap-Belegung und der Zuordnungsaktivität auslöst, wird in vielen Fällen kein Heap-Speicher zurückgegeben, es sei denn, dies wird extern erzwungen. Dieses Verhalten war in Containerumgebungen nachteilig, in denen Ressourcen durch Nutzung bezahlt werden. Selbst wenn die JVM aufgrund von Inaktivität nur einen Bruchteil ihres zugewiesenen Speichers verwendet, behält G1 den vollen Heap bei. Kunden zahlten also ständig für alle Ressourcen, und Cloud-Anbieter konnten ihre Hardware nicht vollständig nutzen.

Mit Java 12 kann die JVM Phasen der Heap-Unterauslastung erkennen und die Heap-Nutzung während dieser Zeit automatisch reduzieren. 

JVM-Konstanten-API

Diese API modelliert nominelle Beschreibungen von Datei- und Laufzeitartefakten der Schlüsselklasse, insbesondere von Konstanten, die aus dem Konstantenpool geladen werden können. Java 12 definiert eine Familie wertbasierter symbolischer Referenztypen in einem neuen Paket, java.lang.invoke.constantum jede Art von ladbarer Konstante zu beschreiben.

In jeder Java-Klasse sind konstante Pools vorhanden, in denen Operanden und Bytecode-Anweisungen in der Klasse gespeichert sind. Einträge im Konstantenpool beschreiben entweder Laufzeitartefakte wie Klassen und Methoden oder einfache Werte wie Zeichenfolgen und Ganzzahlen. Diese Einträge werden als ladbare Konstanten bezeichnet.

Programme, die Klassendateien bearbeiten, müssen Bytecode-Anweisungen und wiederum ladbare Konstanten modellieren. Die Verwendung von Standard-Java-Typen zum Modellieren ladbarer Konstanten ist jedoch unzureichend. Dies kann für eine ladbare Konstante, die eine Zeichenfolge beschreibt, akzeptabel sein, ist jedoch für eine ladbare Konstante, die eine Klasse beschreibt, problematisch, da das Erstellen eines "lebenden" ClassObjekts von der Richtigkeit und Konsistenz des Ladens der Klasse abhängt. Das Laden von Klassen weist jedoch viele Umgebungsabhängigkeiten und Fehlermodi auf.

Programme, die sich mit ladbaren Konstanten befassen, könnten also vereinfacht werden, wenn sie Klassen und Methoden sowie weniger bekannte Artefakte wie Methodenhandles und dynamisch berechnete Konstanten in einer nominalen symbolischen Form manipulieren könnten. Daher bietet die JVM-Konstanten-API Bibliotheken und Tools eine einzige Standardmethode zur Beschreibung ladbarer Konstanten.

Verbesserte Start-, CDS- und Garbage Collection

Java 12 erweitert den JDK-Erstellungsprozess, um ein Standard-CDS-Archiv (Class Data Sharing) unter Verwendung der Standardklassenliste auf 64-Bit-Plattformen zu generieren. Dies verbessert die sofort einsatzbereite Startzeit und macht die Ausführung -Xshare:dumpüberflüssig, um vom CDS zu profitieren. Der JDK-Erstellungsprozess wurde so geändert, dass er java-xshare:dumpnach dem Verknüpfen des Images ausgeführt wird.

Zusätzliche Befehlszeilenoptionen wurden hinzugefügt, um die Heap-Zeiten für die Speicherbereinigung zu optimieren und das Speicherlayout für häufige Fälle zu verbessern. Benutzer mit erweiterten Anforderungen, wie z. B. benutzerdefinierten Klassenlisten, die Anwendungsklassen und verschiedene Garbage Collection-Konfigurationen enthalten, können weiterhin ein benutzerdefiniertes CDS-Archiv erstellen.

Reduzierte Anzahl von ARM-Ports

Java 12 entfernt alle Quellen, die sich auf den arm64Port beziehen, während der 32-Bit-ARM und der 64-Bit-ARM beibehalten werden aarch64. Durch das Entfernen dieses Ports könnten sich die Mitwirkenden auf eine einzelne 64-Bit-ARM-Implementierung konzentrieren und Doppelarbeit vermeiden, die sich aus der Wartung von zwei Ports ergeben würde. Derzeit befinden sich zwei 64-Bit-ARM-Ports im JDK.

Ausdrücke wechseln

Switch-Ausdrücke vereinfachen die Codierung, indem sie die switchAnweisung erweitern, sodass sie entweder als Anweisung oder als Ausdruck verwendet werden kann. Dies ermöglicht sowohl Anweisungen als auch Ausdrücken, entweder "traditionelles" oder "vereinfachtes" Scoping zu verwenden und das Flussverhalten zu steuern. Diese Änderungen führen zu einer einfacheren „alltäglichen“ Codierung und bereiten den Weg für die Verwendung des Mustervergleichs in switch.

Während Java-Builder die Mustererkennung unterstützen, sind Unregelmäßigkeiten der Java-  switchAnweisung zu Hindernissen geworden. Dazu gehört das Standard-Kontrollflussverhalten von Schaltblöcken. Standardbereich von Switch-Blöcken, in denen der Block als ein einziger Bereich behandelt wird; und Schalter funktioniert nur als Anweisung. Das aktuelle Design der Java- switchAnweisung folgt genau Sprachen wie C ++ und unterstützt standardmäßig die Fallthrough-Semantik. Dieser Kontrollfluss war nützlich, um Code auf niedriger Ebene zu schreiben. Wenn Switch jedoch in übergeordneten Kontexten verwendet wird, überwiegt seine Fehleranfälligkeit die Flexibilität.

Grundlegende Benchmark-Suite

JDK 12 enthält eine grundlegende Suite von Mikrobenchmarks, die dem Quellcode der Plattform hinzugefügt wurden. Ziel ist es, Entwicklern das Ausführen vorhandener oder das Erstellen neuer Benchmarks zu erleichtern.

Der Vorschlag für eine Microbenchmarks-Suite, der im Juli 2014 erstellt und Anfang November 2018 aktualisiert wurde, wurde vom Java Microbenchmark Harness (JMH) zur Erstellung von Benchmarks in Java und anderen JVM-Sprachen unterstützt. Die Suite ist mit JDK-Quellcode in einem einzigen Verzeichnis zusammengefasst, sodass Entwickler problemlos neue Benchmarks hinzufügen können.

Es war nicht das Ziel, Benchmarks für neue JDK-Funktionen bereitzustellen oder einen vollständigen Satz von Benchmarks zu erstellen, die alles im JDK abdecken. Beachten Sie auch, dass die Benchmarking-Suite für reguläre JDK-Builds nicht erforderlich ist, sondern ein separates Build-Ziel darstellt. 

Der Vorschlag sah die Erstellung einer neuen Seite auf wiki.openjdk.java.net vor, auf der erläutert wird, wie Benchmarks entwickelt und Anforderungen beschrieben werden. Diese Anforderungen erfordern die Einhaltung von Codierungsstandards, reproduzierbarer Leistung und Dokumentation.

JDK 12-Updates

Geplant ist, dass JDK 12 zwei Updates erhält, bevor JDK 13 in sechs Monaten erfolgreich sein wird. JDK 12 ist Teil der sechsmonatigen Release-Trittfrequenz von Oracle, die im September 2017 mit JDK 9 eingeführt wurde. JDK 12 ist im Gegensatz zu JDK 11, einem langfristigen Support-Release mit mehreren Jahren Support, als Feature-Release gekennzeichnet.