Alles Aberglaube?

Release-Candidate-Phase für Java 13 gestartet

Dominik Mohilo

© Shutterstock / Oleksandr Kostiuchenko

Die Zahl 13 wird oft mit Pech oder Unglück verbunden: viele Hotels haben kein Zimmer mit dieser Nummer, Freitag der 13. gilt als Unglückstag. Hoffentlich sind dies keine bösen Vorboten für Java 13, das im Herbst dieses Jahres erscheinen soll. Wann genau es erscheinen soll, wurde bereits Anfang April 2019 festgelegt. Zuverlässig wie ein Schweizer Uhrwerk startete am 18. Juli ganz nach Plan die zweite Rampdown-Phase. In der Release-Candidate-Phase heißt es seit 8. August, die letzten Bugs auszumerzen.

Viele Projekte im Java-Universum sind noch im Entstehen begriffen, etwa Projekt Valhalla, Projekt Amber oder Projekt Skara. Ob und wann diese veröffentlicht werden, steht noch in den Sternen. Die Funktionen, die aller Voraussicht nach Teil von Java 13 sein werden, stehen allerdings bereits fest: JEP 350 (Dynamic CDS Archives), JEP 351 (ZGC: Uncommit Unused Memory), 353 (Reimplement the Legacy Socket API), JEP 354 (Switch Expressions) und JEP 355 (Text Blocks). Nicht in die Rampdown-Phase hatte es JEP 343 (Packaging Tool) geschafft, dieses wird vielleicht mit Java 14 ausgeliefert. Wir haben uns unter anderem die neuen Features angesehen, die mit JDK 13 an die Entwicklergemeinde ausgeliefert werden, außerdem gehen wir an dieser Stelle auf die Release-Candidate-Phase ein.

Java 13 in der Release-Candidate-Phase

Seit der Rampdown-Phase 1 befindet sich Java 13 im Feature Freeze, daran wird sich auch nichts mehr ändern bis zum Release. Neue Features kommen also in dieser Phase auch nicht mehr hinzu, neue JEPs können frühestens für das JDK 14 vorgemerkt werden. War es in der Rampdown-Phase noch möglich, Verbesserungen für bestehende Funktionen einzupflegen, allerdings war die Hürde dafür laut Mark Reinhold extrem hoch. In der Release-Candidate-Phase gibt es nun lediglich noch ein umfangreiches Bughunting und Bugfixing. Eine Liste der noch zu bearbeitenden Bugs kann im Bugtracking-System gefunden werden. Aktuell gibt es allerdings keine Fehler, die noch zu beheben sind.

Die voraussichtliche Release Schedule

Java 12 wurde plangemäß am 19. März veröffentlicht, darüber berichteten wir ausführlich (Java 12: Alle neuen Features auf einen Blick & Java 12: „Der neue Release-Zyklus hat sich als unglaublich effektiv erwiesen“). Nun steht das nächste Release an, Java 13, welches im Herbst erscheinen soll. Bereits am 18. März, also vor der Veröffentlichung von Java, hat Mark Reinhold, Chief Architect der Java Platform Group bei Oracle, auf der JDK-Dev Mailing-Liste die geplanten Termine für den Release-Prozess veröffentlicht und um Feedback gegeben. Da es keine Probleme gab, wurde folgende Plan festgelegt:

Datum Phase
13. Juni Rampdown Phase One
18. Juli Rampdown Phase Two
08. August Initial Release Candidate
22. August Final Release Candidate
17. September General Availability

Java 13: Die neuen Features

Die erste Rampdown-Phase begründete wie immer die Zeit, in der dem JDK keine neuen Funktionen und Features mehr hinzugefügt wurden, es herrscht seitdem der sogenannte Feature Freeze. Auf der Projektseite sind jene JEPs veröffentlicht worden, aus denen das JDK 13 bestehen wird: JEP 350, JEP 351, JEP 353, JEP 354 und JEP 355, wobei JEP 355 den veralteten Kandidaten JEP 326 ersetzt. Eine weitere mögliche und nicht-technische Änderung, wurde von Brian Goetz im Java Expert Group Meeting im Januar vorgebracht: In Zukunft sollte keine Abstimmung mehr nötig sein, JSRs für neue Java-Versionen zu starten (für das kommende Java Release ist JSR 388 vorgesehen).

W-JAX 2019 Java-Dossier für Software-Architekten

Kostenlos: Java-Dossier für Software-Architekten 2019

Auf über 30 Seiten vermitteln Experten praktisches Know-how zu den neuen Valuetypes in Java 12, dem Einsatz von Service Meshes in Microservices-Projekten, der erfolgreichen Einführung von DevOps-Praktiken im Unternehmen und der nachhaltigen JavaScript-Entwicklung mit Angular und dem WebComponents-Standard.

 

JDK 13: Das sind die neuen Features

JEP 350 – Dynamic CDS Archives

Da die Usability beim Teilen der Klassendaten von Anwendungen (Application Class-Data Sharing – AppCDS) ein wenig zu wünschen übrig lässt, wurden die neuen dynamischen CDS-Archive vorgeschlagen. Diese würden die in Java 10 erstmals enthaltene Funktionalität insofern erweitern, dass am Ende der Ausführung einer Java-Anwendung die entsprechenden Klassen – wie der Name schon sagt – dynamisch archiviert werden. In diesen Archiven enthalten wären dann alle Anwendungsklassen, die zuvor geladen wurden und sämtliche Bibliotheksklassen, die nicht im Standard Base-Layer-CDS-Archiv enthalten sind. Nutzer müssten so keine Probeläufe mehr für das Erstellen von Klassenlisten für jede einzelne Anwendung durchführen. Zukünftig könnte dann durchaus auch eine automatische Erstellung von Archiven beim ersten Starten einer Anwendung möglich werden, was die Nutzung von CDS/AppCDS komplett automatisiert und transparent machen würde.

JEP 351 – Uncommit Unused Memory

In JEP 351 geht es konkret um den Garbage Collector ZGC, der leider in seiner derzeitigen Form ungenutzten Heap-Speicher nicht ans Betriebssystem zurückgibt. ZGC besteht aus sogenannten Heap-Regionen (ZPages), für die ein gewisser Teil des Speichers festgelegt (committed) wird. Komprimiert ZGC den Heap, werden die ZPages in einen Page-Cache eingebettet (ZPageCache) und können bei Bedarf für neu aufkommenden Heap wiederverwendet werden. Da die ZPages ohnehin schon nach ihrer letzten Nutzung und nach drei verschiedenen Größen (klein, mittelgroß, groß) sortiert im Cache hinterlegt sind, soll ein (Standard-)Zeitwert definiert werden, nach dem eine bestimmte ZPage (und der damit verbundene Speicher) wieder freigegeben wird. Im Shenandoah GC ist dies bereits umgesetzt, dort wird ungenutzter Speicher standardmäßig nach 5 Minuten wieder „uncommittet“. Der Wert ist zudem via Kommandozeile mit dem Befehl -XX:ShenandoahUncommitDelay=<milliseconds> frei definiertbar.

JEP 353 – Reimplement the Legacy Socket API

Unter dem Decknamen Project Loom wird unter anderem die Implementierung sogenannter Fibers (leichtgewichtige User-Threads) vorangetrieben. Diese neuen Technologien verändern auch den Blick auf bereits altgediente APIs, etwa java.net.Socket und java.net.ServerSocket. Diese Schnittstellen und deren Implementierung ist bereits seit JDK 1.0 an Bord und offenbar recht schwierig auf Stand und am Laufen zu halten (bestehend aus einem Wirrwarr von veraltetem Java- und C-Code). JEP 353 sieht vor, PlainSocketImpl, also die alte Implementierung, durch eine neue zu ersetzen: NioSocketImpl. Diese ist ähnlich wie die New I/O-Implementierung (NIO) aufgebaut und soll ebenso einfach zu Verwalten und Debuggen sein.

JEP 354 – Switch Expressions (Überarbeitet)

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 wird 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 bleiben die Switch Expressions unverändert.

JEP 355 – Text Blocks

JEP 326 sah vor, sogenannte Raw String Literals der Programmiersprache bereits in Version 12 hinzuzufügen. Ein solches Raw String Literal kann sich über mehrere Code-Zeilen erstrecken und interpretiert keine Escape-sequenzen wie \n oder Unicode-Escape-Sequenzen wie \uXXXX. Im Gegensatz zu traditionellen String-Literalen, sollten die neuen, ergänzenden Raw Literale nicht interpretiert, sondern wie sie sind als String erzeugt werden. Sozusagen „roh und unbehandelt“ sollten sie es Entwicklern leichter machen, Zeichensequenzen in lesbarer Form und frei von Java-Indikatoren ausdrücken zu können. Dieses JEP wurde viel diskutiert und schließlich auf die lange Bank geschoben, da es dringender Überarbeitungen bedürfe, wie Brian Goetz es auf der Amber-Spec-Experts Mailing-Liste zur Debatte stellte. Engagierte Java-Entwickler wurden dazu aufgerufen, dort Input zu geben und sich an dem Prozess zu beteiligen.

Nun wurde JEP 355 angekündigt, mit dem der neue Typ Text Block eingeführt werden soll. Die Bemühungen des JEPs basieren auf den Grundlagen, die bereits für JEP 326 und die Raw String Literals geschaffen wurde. Die im Vorschlag beschriebenen Textblöcke sollen, dem entsprechenden JEP Draft zufolge, mehrzeilige String-Literale darstellen. Ihre Formatierung soll einheitlichen Regeln unterliegen und sich an der Darstellung des Texts im Quellcode orientieren, sodass Entwickler nicht zwingend auf Befehle zurückgreifen müssen, um das Layout des Texts zu beeinflussen. Zu den Zielen, die mit der Einführung von Text Block verbunden werden, gehört unter anderem das leichtere Gestalten mehrzeiliger Strings für Programmierer. Durch die Regeln zur automatischen Formatierung wären bei einer Einführung des Typs keine Escape-Sequenzen im Stil von \n nötig. Insbesondere solche Java-Programme, die Code anderer Programmiersprachen innerhalb von Strings enthalten, sollen mit dem neuen Format besser lesbar werden.

Mögliche Features in 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 zu dem aktuellen Zeitplan für Java 13 gibt es auf der JDK-Dev Mailing-Liste, die finalen JEPs finden sich auf der Projektseite für das JDK 13.

Java 14: Es hat begonnen!

Verwandte Themen:

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

2 Kommentare auf "Release-Candidate-Phase für Java 13 gestartet"

avatar
4000
  Subscribe  
Benachrichtige mich zu:
Bughunter
Gast

Java 13 dann auch mit Zeitschleifen? Sonst wird’s schwer mit rückwärts laufender Zeit zwischenden beiden Release Candidates.