Alles Aberglaube?

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

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 das gerade erschienene Java 13. Bereits Anfang April 2019 war festgelegt worden, wann das neue JDK das Licht der Welt erblicken sollte – und der Plan wurde wie erwartet eingehalten. Neben einer kurzen Übersicht über die Highlights, bieten wir auch für dieses Release wieder unsere hübsche JDK-Infografik zum kostenlosen Download an.

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. Auch in Bezug auf Java 13 war es bis zur Rampdown-Phase noch unklar, welche JEPs es ins finale Release schaffen würden. Das sind diesmal: 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 die neuen Features angesehen, die mit JDK 13 an die Entwicklergemeinde ausgeliefert werden, außerdem geben wir unseren Lesern an dieser Stelle wieder unsere hübsche Infografik mit einer kurzen Übersicht über die JEPs an die Hand.

Java 13: Die Infografik

Stimmen zum Release

Wie immer gab es zum Release der neuen Java-Version auch einige offizielle Stimmen. Georges Saab, Vice President of Development, Java Platform bei Oracle, schrieb etwa:

The JDK 13 release is the result of industry-wide development involving open review, weekly builds and extensive collaboration between Oracle engineers and members of the worldwide Java developer community via the OpenJDK Community and the JCP. The goal is always to make the latest innovation in the Java SE Platform and the JDK easily accessible to developers globally. We invite the community to share their experience with Java SE 13, and continue to contribute and help make Java even better in future releases.

Auch wir haben in die Community hineingehorcht und mit den Java-Profis Michael Simons, Tim Riemer, Michael Vitz, Sandra Parsick, Christian Schneider, Tim Zöller und Hendrik Ebbers über ihre Highlights der aktuellen Java-Version, ihre Meinung zur Release-Kadenz und ihre Wünsche für JDK 14 gesprochen:

7 Experten – 7 Meinungen: Was sind eure Highlights in Java 13?

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. 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). Wie und ob dies umgesetzt wird, steht noch nicht fest.

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.

Java 13: Alle Features der neuen Version im Detail

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.

Textblöcke in Java 13: Warum sich das lange Warten gelohnt hat

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.

Die finalen JEPs finden sich auf der Projektseite für das JDK 13.

Java 14: Erstes Feature mit Target JDK 14

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

3 Kommentare auf "Java 13 ist da – die Highlights in der Übersicht [mit Infografik]"

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.

Felix Dombek
Gast

‚ ist eigentlich kein Backquote, sondern `