7+7

Java 14: Preview Features und ein Garbage Collector auf dem Abstellgleis

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. Wir haben alle bereits verfügbaren Informationen zum JDK 14 an dieser Stelle zusammengetragen. Aktuell sind die Preview Features im Fokus, außedem soll der Concurrect Mark Sweep Garbage Collector endlich in den wohlverdienten Ruhestand geschickt werden.

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 einzigen sonst bekannten Daten sind die öffentliche Review Phase, die im Dezember diesen oder Januar nächsten Jahres beginnen soll und das ungefähre Release-Datum (März 2020). Zudem haben Entwickler bereits die Möglichkeit, wie man auch auf Twitter lesen kann, Early Access Builds auszuprobieren.

Good-bye, Mark Sweep Garbage Collector

Noch ist es kein offizielles JEP, doch als Draft ist die von Thomas Schatzl gewünschte Änderung bereits vorgeschlagen worden: 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.

Ein weiteres JEP Draft, das sich mit der Garbage Collection befasst, wurde von Erik Österlund erstellt. Ziel des Proposals ist, 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 wird aller Voraussicht nach in Java 13 enthalten sein.

Java 14: 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.

Die möglichen neuen 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. JEP 352 (Non-Volatile Mapped Byte Buffers) ist etwa bereits explizit für Java 14 vorgeschlagen worden. Den Sprung in Java 13 hat JEP 343 (Packaging Tool) verpasst, möglicherweise klappt es aber 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).

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.

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.

Release-Candidate-Phase für Java 13 gestartet

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: Preview Features und ein Garbage Collector auf dem Abstellgleis"

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.