Alles Aberglaube?

Java 13: Überarbeitung der Switch Expressions & mehrzeilige String-Literale für JDK 13

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. Mittlerweile sind drei JEPs definitiv für die Implementierung in JDK 13 geplant, drei weitere Proposals stehen zur Diskussion.

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. Doch es gibt auch Funktionen, die mit großer Wahrscheinlichkeit in Java 13 erscheinen werden. Etwa JEP 350 (Dynamic CDS Archives), JEP 351 (ZGC: Uncommit Unused Memory) und 353 (Reimplement the Legacy Socket API). Diese drei JEPs sind „targeted“, werden also aller Wahrscheinlichkeit nach in JDK 13 enthalten sein.

Doch es gibt auch neue JEPs, die für Java 13 vorgeschlagen wurden: JEP 343 (Packaging Tool), JEP 354 (Switch Expressions) und JEP 355 (Text Blocks). Diese haben den Status „proposed“ und ihre Implementierung in JDK 13 ist noch auf der Kippe. Wir haben uns die neuen Features angesehen, die aller Voraussicht nach mit JDK 13 an die Entwicklergemeinde ausgeliefert werden.

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

Da die Entwicklung von Java 13 noch in den sprichwörtlichen Kinderschuhen steckt, gibt es natürlich noch keine definitiven Zusicherungen, welche Funktionen die neue Java-Version enthalten wird. Eine Änderung, die aber sehr wahrscheinlich ist, 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). Projekte, die für das neue JDK in Frage kommen, gibt es viele (siehe oben). Noch sind zwar keine JEPs, die definitiv Teil des JDK 13 werden, bekannt und auf der Projektseite veröffentlicht worden, doch es gibt die ersten Vorschläge: JEP 350, JEP 351 und JEP 353 sind bereits für die Veröffentlichung vorgesehen, JEP 343, JEP 354 und JEP 355 wurden vorgeschlagen, wobei JEP 355 den veralteten Kandidaten JEP 326 ersetzt.

Targeted to JDK 13

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.

Porposed to JDK 13

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 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.

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.

Records & Sealed Types: Neue Typen für Java

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 "Java 13: Überarbeitung der Switch Expressions & mehrzeilige String-Literale für JDK 13"

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.