7+7

Java 14: Z Garbace Collector auch für Windows und Adieu, Kombination aus ParallelScavenge & SerialOld

Dominik Mohilo

© Shutterstock / Oleksandr Kostiuchenko

Mit Java 14 ist die dritte Version seit dem letzten Release mit Long-Term-Support in Arbeit. Java 12 und Java 13 wurden bzw. werden mit einer recht überschaubaren Anzahl an neuen Features ausgeliefert, für Java 14 wird sich dieses Schema aller Voraussicht nach nicht ändern. Dies ist natürlich der neuen Veröffentlichungskadenz zu verdanken. Dennoch gibt es mittlerweile 10 JEPs, die aller Voraussicht nach für JDK 14 umgesetzt werden und die Planungsphase ist noch nicht abgeschlossen. Neu ist aktuell JEP 365, durch das der Z Garbage Collector auch für Windows fit gemacht werden soll. JEP 366 betrifft die (fragwürdige) Kombination von ParallelScavenge und OldPrallel.

Ob wir in Java 14 wohl Features aus Projekt Valhalla oder Projekt Amber sehen werden? Das steht noch in den Sternen. Auch ob Git, wie in Projekt Skara aktuell geprüft wird, Mercurial für das JDK ersetzt ist noch nicht abschließend entschieden. Aber die Arbeit an Java 14 hat ja auch gerade erst begonnen und es fließt noch viel Wasser den Rhein herunter, bevor das nächste JDK verfügbar sein wird.

Aktuell wurde zudem ein neues Projekt ins Leben gerufen, Project Lanai, bei dem es um eine neue 2D-Rendering-Pipeline für das JDK und OpenJFX für macOS geht.

JDK 14: Was bisher bekannt ist

Der erste Schritt auf dem Weg zum nächsten Java Release wurde im Juni gemacht, denn im vergangenen Monat wurde die Expert Group formiert. Teil dieser sind Simon Ritter (Azul Systems), Manoj Palat (Eclipse Foundation), Tim Ellison (IBM), Andrew Haley (Red Hat), Volker Simonis (SAP SE), Iris Clark (Oracle) und natürlich Brian Goetz (ebenfalls Oracle).

Die Release Schedule

Wie gewohnt hat Mark Reinhold auf der jdk-dev Mailing-Liste die geplante Release Schedule veröffentlicht. Dies ist, da keine Einsprüche erhoben worden sind, der finale Plan. So sieht also die Release Schedule für Java 14 aus:

Datum Ereignis
12. Dezember 2019 Start Rampdown-Phase Eins
16. Januar 2020 Start Rampdown-Phase Zwei
06. Februar 2020 Veröffentlichung initialer Release Candidate
20. Februar 2020 Veröffentlichung finaler Release Candidate
17. März 2020 Veröffentlichung Java 14

Zudem haben Entwickler bereits die Möglichkeit, wie man auch auf Twitter lesen kann, Early Access Builds auszuprobieren. Der aktuellste ist vom 8. Oktober 2019:

JDK 14: Das sind die neuen Features

Proposals kann es viele geben, Drafts noch viel mehr, doch welche Features ernsthaft für eine Veröffentlichung in einem bestimmten JDK vorgesehen sind, erhalten das Tag „Targeted“. Bisher sind bereits drei JEPs definitiv für Java 14 vorgesehen (349 / 352 / 358), sieben weitere wurden aktuell mit dem Tag „Proposed to Target“ (345 / 361 / 363 / 364 / 365 / 366 / 367) ausgestattet.

JEP 345 – NUMA-Aware Memory Allocation for G1

Mehrkernprozessoren sind mittlerweile der allgemeine Standard. In einer NUMA-Arbeitsspeicher-Architektur erhält jeder Kern des Prizessors einen lokalen Arbeitsspeicher, auf den die anderen Kerne allerdings Zugriff gewährt wird. JEP 345 sieht vor, den G1 Garbace Collector mit der Möglichkeit auszustatten, solche Architekturen vorteilhaft zu nutzen. Damit soll unter anderem die Performance auf sehr leistungsstarken Maschinen erhöht werden. Das JEP 345 dient dabei ausschließlich für die Implementierung des NUMA-Supports für den G1 Garbage Collector, nur für das Speichermanagement (Memory Allocation) und auch nur unter Linux. Ob also diese Unterstützung von NUMA-Architekturen auch für andere Garbage Collectors kommt oder für andere Teile wie etwa das Task Queue Stealing kommt, ist nicht bekannt.

JEP 349 – JFR Event Streaming

Der Java Flight Recorder (JFR) ist mittlerweile Teil des OpenJDKs und damit frei verfügbar. Mit JEP 349 wird vorgeschlagen, ein API zu erstellen, über das die vom Java Flight Recorder erhobenen Daten für die kontinuierliche Überwachung von aktiven und inaktiven Anwendungen genutzt werden können. Dabei sollen die gleichen Events aufgenommen werden, wie bei der nicht-streaming-Variante, der Overhead soll weniger als 1 Prozent betragen. Event Streaming würde so mit der nicht-streaming-Variante gleichzeitig durchgeführt werden. JEP 349 soll allerdings keine snychronen Callbacks für den jeweiligen Konsumenten ermöglichen, auch Daten aus Recordings, die im Zwischenpeicher liegen sollen nicht verfügbar gemacht werden. Technisch würde das Package jdk.jfr.consumer im Modul jdk.jfr durch die Funktionalität erweitert werden, asynchron auf Events zugreifen zu können.

JEP 352 – Non-Volatile Mapped Byte Buffers

JEP 352 sieht vor, MappedByteBuffer um die Fähigkeit zu erweitern, den Zugriff auf nichtflüchtige Datenspeicher (NVM) zu erweitern. Diese Speicher (auch als persistente Speicher bekannt) werden eingesetzt, um Daten dauerhaft zu speichern. Das Java Enhancement Proposal hat in Bezug auf das JDK API ein neues Modul und eine neue Klasse im Gepäck: Das Modul jdk.nio.mapmode kann genutzt werden, um den MappedByteBuffer zu erstellen (read-write oder read-only), der über eine Datei auf einem NVC gemappt ist. Die Klasse ManagementFactory macht es möglich, eine Liste von BufferPoolMXBean-Instanzen über die Methode List<T> getPlatformMXBeans(Class<T>) zu erhalten. Diese wird so modifiziert, dass sie gewisse Statistiken für sämtliche durch obiges Modul gemappte MappedByteBuffer-Instanzen erfasst.

JEP 358 – Helpful NullPointerExceptions

Programme, und da machen auch Java-Anwendungen keine Ausnahme, bestehen in der Regel aus einer Vielzahl an Methoden, Objekten, Funktionen, Annotationen und so weiter. Und in diesem großen Sammelsurium aus Kleinteilen kann praktisch überall eine sogenannte NullPointerException (NPE) auftreten. Dieses Problem soll von JEP 358 gelöst werden. Durch eine Analyse der Bytecode-Anweisungen eines Programms soll die JVM zukünftig präzise aufzeigen können, welche Variable einen Nullwert ergibt. Daraufhin soll die JVM eine null-detail message in der NullPointerException ausgeben, die neben der bislang üblichen Meldung erscheint. Das obige Beispiel würde dann wie folgt aussehen:

Exception in thread "main" java.lang.NullPointerException: 
        Cannot assign field 'i' because 'a' is null.
    at Prog.main(Prog.java:5)

Entsprechend würde die Nachricht für das etwas komplexere Beispiel (a.b.c.i = 99;) so erscheinen:

Exception in thread "main" java.lang.NullPointerException: 
        Cannot read field 'c' because 'a.b' is null.
    at Prog.main(Prog.java:5)

Ziel des JEP 358 ist es, so die Autoren, Entwicklern wichtige und hilfreiche Informationen für die Fehlerbehebung direkt an die Hand zu geben. Neue Entwickler wären so weniger verwirrt und besorgt über NPEs und das allgemeine Verständnis eines Programms könnte so auch verbessert werden.

JEP 361 – Switch Expresisons (Standard)

In unserem Experten-Check zu Java 14 haben wir sieben Experten nach ihren Wünschen für die kommende Java-Version gefragt. Der Wunsch, dass die bisher nur als „Preview Feature“ verfügbaren Switch Expressions den GA-Status erreichen (und neben ihnen auch die Text Blocks), wurde mehrfach gesagt.

Mit JEP 325 (Switch Expressions) wurde vorgeschlagen, die switch-Anweisung zu erweitern, sodass sie entweder als Anweisung (Statement) oder als Ausdruck (Expression) genutzt werden kann. Beide Formen sollten dabei in der Lage sein, entweder „traditionelle“ oder „simplifizierte“ Variablen und Kontrollstrukturen zu nutzen. Ziel dieses JEPs war es, das tägliche Programmieren zu vereinfachen und den Weg für Pattern Matching (JEP 305) in Verbindung mit der Anweisung switch zu ebnen.

Durch diesen Vorschlag ändert sich zunächst die Schreibweise beim case. Neben dem offensichtlichen Pfeil statt des Doppelpunkts können seit Java 12 testweise auch mehrere Werte aufgeführt werden. Bemerkenswert ist vor allem, dass kein break mehr benötigt wird, wie Michael Inden in seinem Fachartikel zum Thema ausführt.

Mit JEP 354 wurde von Gavin Bierman vorgeschlagen, die Funktionsweise noch ein wenig anzupassen. Um einen Wert von einer Switch Expression auszugeben, soll nun die value-Anweisung durch eine yield-Anweisung ersetzt werden. Ansonsten blieben die Switch Expressions unverändert und sollen nun in diesem Status Teil einer der nächsten Java-Versionen werden – vielleicht sogar schon Teil von Java 14. Eine kleine Einführung in das Thema hat Michael Inden in seinem Artikel auf JAXenter gegeben.

JEP 363 – Remove the Concurrent Mark Sweep (CMS) Garbage Collector

Nun ein offizielles JEP (363) ist eine von Thomas Schatzl vorgeschlagene Änderung: Der Concurrent Mark Sweep (CMS) Garbage Collector soll, nachdem er bereits in Java 9 (JEP 291) als veraltet markiert worden ist. Zwei Jahre hatten, so Schatzl, interessierte User Zeit, sich des Projektes anzunehmen. Da dies bislang nicht der Fall war, soll nun die letzte Reise für Mark Sweep vorbereitet werden.

Nutzer älterer Java-Versionen, die auf den CMS GC setzen, können aber beruhigt aufatmen: Es ist nicht Ziel, den Garbage Collector aus früheren Releases des JDKs zu entfernen. Gleiches gilt, auch wenn dies eigentlich nicht erwähnt werden muss, für andere Müllsammler wie Shenendoah oder ZGC. Diese bleiben im JDK enthalten und haben mit dem neuen JEP Draft nichts zu tun.

JEP 364 – ZGC on macOS

Auch JEP 364 befasst sich mit der Garbage Collection und wurde von Erik Österlund erstellt. Ziel des Proposals ist es, den Z Garbage Collector auch für macOS-Nutzer als Option zur Verfügung zu stellen. Teil des JEPs soll gleichzeitig auch die Funktionalität des Collectors sein, ungenutzten Speicher für das System wieder freizugeben, wie es in JEP 351 vorgeschlagen wurde. Diese Funktionalität ist seit Java 13 im JDK enthalten.

JEP 365 – ZGC on Windows

JEP 365 ist praktisch der gleiche Vorschlag, wie JEP 364. Der einzige Unterschied ist, bei JEP 365 geht es um die Bereitstellung des Z Garbage Collectors (ZGC) für Windows. Der Großteil der Cose-Basis des ZGC ist plattformunabhängig, es sollte also nur ein geringer Entwicklungsaufwand sein, ihn auch für Windows fit zu machen. Einschränkungen gibt es bei der Kompatibilität zu älteren Windows-Versionen: Windows 10 und Windows Server sollten nicht älter als Version 1803 sein, da ältere Versionen nicht das benötigte API für Speicherreservierungen beinhalten.

JEP 366 – Deprecate the ParallelScavenge + SerialOld GC Combination

Auch in JEP 366 geht es um die Garbage Collectoren, bzw. in diesem Fall um eine Kombination aus zwei „Müllsammlern“: ParallelScavenge und SerialOld. Der Vorschlag ist, die Kombination der Algorithmen der beiden als Deprecated zu markieren, da wohl nur sehr weniger Entwickler sie in dieser Form einsetzen. Am Ende geht es hier um den Kosten-Nutzen-Faktor, denn diese Kombination aktuell zu halten erfordert einen erheblichen Aufwand, bedenkt man die Seltenheit der tatsächlichen Nutzung. Komplett ausgebaut soll die Kombination, die via -XX:UseParallelGC und -XX:-UseParallelOldGC aufgerufen wird, allerdings nicht werden. Der Garbace Collector Parallel ist allerdings in Augen von Thomas Schatzl, der dieses JEP vorgeschlagen hat, eine gute Alternative.

JEP 367 – Remove the Pack200 Tools and API

Das Kompressionsshema Pack200, das für die Komprimierung von JAR-Dateien genutzt wird, ist bereits seit Java 11 als veraltet markiert. JEP 367 ist nun das offizielle Proposal, um die Tools pack200 und unpack200 sowie das Pack200 API aus dem Package java.util.jar zu entfernen. Die Technik ist seinerzeit in Java 5 eingeführt worden und diente als Reaktion auf die damals noch sehr begrenzte Bandbreite (56k Modems) und den geringen Speicherplatz auf Festplatten. Mit Java 9 wurden bereits vor einiger Zeit neue Kompressionsschemata eingeführt, Entwicklern wird empfohlen, jlink zu nutzen.

7 Experten – 7 Meinungen: Welche Wünsche habt ihr für Java 14?

Weitere mögliche Features von Java 14

Wie immer sind, besonders in dieser frühen Phase, Angaben ohne Gewähr. Dennoch gibt es bereits einige Features, die möglicherweise in Java 14 auftauchen werden. Dazu zählt beispielsweise JEP 343 (Packaging Tool), das den Sprung ins JDK 14 verpasst hat – vielleicht klappt es ja mit Java 14.

JEP 343 – Packaging Tool

Wer hätte gedacht, dass man JavaFX vielleicht doch noch einmal vermissen würde? Mit JDK 8 wurde auch ein Tool javapackager veröffentlicht, das als Teil von JavaFX im Kit enthalten war. Nachdem JavaFX allerdings mit dem Release von JDK 11 aus Java herausflog, war auch der beliebte javapackager nicht mehr verfügbar. Das Packaging Tool sorgte dafür, das Java-Anwendungen so verpackt werden konnten, dass sie wie alle anderen Programme installiert werden konnten. Für Windows-Nutzer konnten so etwa *.exe-Dateien erstellt werden, deren enthaltene Java-Anwendung dann per Doppelklick installiert wurde. Da das Tool schmerzlich vermisst wird, soll ein neues Werkzeug mit Namen jpackage dessen Aufgabe übernehmen. Nutzer können so endlich wieder eigenständige Java-Installationsdateien erstellen, deren Basis die Java-Anwendung und ein Laufzeit-Image sind. Das Tool nimmt diesen Input und erstellt ein Image einer Java-Anwendung, die sämtliche Abhängigkeiten enthält (Formate: msi, exe, pkg in a dmg, app in a dmg, deb und rpm).

Preview APIs

Alle Features, die für die Programmiersprache Java vorgeschlagen werden, müssen ausgiebig getestet werden. Hierfür können Entwickler optional die Verwendung dieser Features aktivieren (Preview Features). Manche dieser Features haben Abhängigkeiten zu APIs, die im Namespace java.* hinterlegt sind. Sind die Preview Features aktiviert, dann gibt es keine bösen Überraschungen. Sollte dies nicht der Fall sein und die APIs werden dennoch aufgerufen, kann es zu Problemen führen, denn die Warnungen, die vom Compiler zur Zeit der Kompilierung ausgegeben werden, haben praktisch keinen Bezug zu den Preview Features. Außerdem können die Warnungen im Code unterdrückt werden.

Abhilfe soll hier die von Joe Darcy vorgeschlagene Funktionalität der Preview APIs schaffen. So sollen zu Preview Features gehörige APIs zukünftig explizit ausgezeichnet werden (etwa java.lang.annotation.PreviewFeature), sodass sie zur Kompilierzeit vom Compiler registriert werden und entsprechende Fehlermeldungen ausgegeben werden, falls Preview Features nicht aktiviert sind. Alex Buckley führt dazu aus:

To be clear: this proposal means there will be APIs in the Java SE Platform that can only be used when preview features are enabled — just as there are already language features in the Platform that can only be used when preview features are enabled.

Neue Dashboards

Manoj Palat, der die Eclipse Foundation in der Expert Group vertritt, brachte im Java Expert Group Meeting im Januar ein interessantes Anliegen vor: Er wünscht sich, neue Dashboards einzuführen, auf denen die Features für die kommenden Java-Versionen übersichtlich und für alle Entwickler und Interessierte zugänglich aufgelistet würden. Brian Goetz’ Standardbedenken, dass die Leute ein solches Dashboard als „feste Zusage“ für das Release bestimmter Features in bestimmten Java-Versionen ansehen würden, wurde selbstverständlich auch vorgebracht. Die Diskussion endete mit dem Zugeständnis, dass Brian sich mit der Thematik intensiver auseinandersetzen wird. So bleibt für Entwickler von Java Tools zu hoffen, dass es bald ein Dashboard geben wird, auf dem sich eine etwas weitreichendere Roadmap für Features abzeichnet.

Weitere Informationen zum Status Quo von Java 14 gibt es auf der offiziellen Projektseite von OpenJDK, Informationen zur Expertengruppe und weitere Links finden sich hier. Mehr zu den Early Access Builds finden Sie auf der entsprechenden Homepage.

Java 13 ist da – die Highlights in der Übersicht [mit Infografik]

Geschrieben von
Dominik Mohilo
Dominik Mohilo
Dominik Mohilo studierte Germanistik und Soziologie an der Goethe-Universität in Frankfurt. Seit 2015 ist er Redakteur bei S&S-Media.
Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "Java 14: Z Garbace Collector auch für Windows und Adieu, Kombination aus ParallelScavenge & SerialOld"

avatar
4000
  Subscribe  
Benachrichtige mich zu:
Entwickler
Gast

Neben Projekt Valhalla und Amber wird es auch für Panama und erst recht für Loom Zeit Bestandteil vom offiziellen JDK zu werden. Mit Loom müßte in den meisten Fällen kein asynchroner Code mehr geschrieben werden. Endlich wieder synchron, blockierend ohne die üblichen Nachteile.