Nicht ganz risikofrei

Java 12: Doch keine Raw String Literals & Finale JEP-Liste

Dominik Mohilo

© Shutterstock / DAN SCANDAL

Java 11 ist pünktlich im September erschienen. Doch dank der neuen Release-Kadenz steht Java 12 bereits in den Startlöchern. Wir haben uns den aktuellen Stand der JEPs angeschaut, Chief Architect Mark Reinhold lieferte hingegen den ersten Entwurf des Fahrplans für JDK 12.

Am 25. September erblickte Java 11 das Licht der Welt. Die neue Version der Programmiersprache ist die zweite, die nach dem neuen Release-Schema veröffentlicht wurde, und brachte die Langzeitunterstützung (LTS, Long-term Support). Durch die neue Kadenz zur Veröffentlichung läuft die Entwicklung von Java 12 allerdings schon auf Hochtouren, am 17. Januar soll die zweite Rampdown-Phase beginnen.

Die voraussichtliche Release Schedule

Mark Reinhold, Chief Architect der Java Platform Group bei Oracle, hatte auf der JDK-Dev Mailing-Liste bereits vor Veröffentlichung von Java 11 die geplanten Termine für Java 12 vorgelegt. Wenig überraschend soll Java 12 im März (genauer: dem 19. März) erscheinen. Wer glaubt, berechtigte Zweifel an den Terminen zu hegen, bzw. arge Probleme aufzeigen kann, die dieser Zeitplan aufweist, konnte diese an entsprechender Stelle in der Mailing-Liste vorbringen, dabei kam ein kleiner Fehler heraus, sodass die Schedule nun wie folgt aussieht:

2018/12/13 Rampdown Phase One
2019/01/17 Rampdown Phase Two
2019/02/07 Release-Candidate Phase
2019/03/19 General Availability

Alten Java-Hasen dürfte bekannt sein, dass in JEP 3 die einzelnen Phasen definiert sind. Im JEP 3 findet jeder, der sich an Java 12 beteiligen will, detaillierte Informationen über die einzelnen Phasen und welche Arbeiten zu diesen Zeitpunkten erledigt werden, bzw. abgeschlossen sein müssen.

Da der einzige Einwand für den Start der ersten Rampdown-Phase am 13. Dezember – gewünscht war der 20. Dezember – im Hinblick auf die dann zu nahen Feiertage abgelehnt wurde, ist der oben abgebildete Zeitplan gemäß des JEP-2.0-Prozess-Proposals offiziell.

JEP 326 – Raw String Literals: Nun also doch nicht, oder?

JEP 326 sieht vor, sogenannte Raw String Literals der Programmiersprache 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, werden die neuen, ergänzenden Raw Literale nicht interpretiert, sondern wie sie sind als String erzeugt. Sie sind sozusagen „roh und unbehandelt“. Damit sollte es Entwicklern zukünftig leichter fallen, Zeichensequenzen in lesbarer Form und frei von Java-Indikatoren ausdrücken zu können. Dieses JEP ist ein Preview Language Feature.

Das Feature selbst ist – dies vorweg – nicht vom Tisch. Wie Brian Goetz auf der JDK-Dev Mailing-Liste schreibt, war man sich jüngst nicht mehr sicher, dass dieses Feature nach dem derzeitigen Stand der Entwicklung wirklich eine Bereicherung für das JDK wäre. Soll heißen: Es ist noch nicht in dem Zustand, in dem es sein soll.

The Preview Feature mechanism is intended for features for which there is a high confidence that the feature is „done“, and the likelihood that significant changes would be made before making the feature permanent is low. At this time, and after extensive consideration, Jim and I no longer believe this to be the case, and we think letting it preview in its current state would be to the detriment of the language. We’re of course disappointed that this means it will take slightly longer for this feature to make it into the language, but we think that’s the best choice.

– Brian Goetz

Für das JDK 12 bedeutet dies, dass die nächste Sprachversion der Java Standard Edition lediglich 8 neue JEPs enthalten wird, denn die Ramdown-Phase hat bereits begonnen. Bedenkt man allerdings, dass der Release-Zyklus ja deutlich beschleunigt worden ist, sollte dieser Schmerz recht einfach zu verkraften sein: Immerhin war ja genau diese nun vorhandene Flexibilität ein Grund für die erneuerte Veröffentlichungspolitik. Unterdessen hat Brian Goeth auf der Amber-Spec-Experts Mailing-Liste die Diskussion über das grundlegende Design der Raw String Literals neu aufgeworfen: Engagierte Java-Entwickler sind dazu aufgerufen, dort Input zu geben und sich an dem Prozess zu beteiligen.

Java 12: Die neuen Features

Die Rampdown-Phase der neuen Java-Version hat begonnen. Damit stehen die acht JEPs, die definitiv Teil des JDK 12 sein werden fest: JEP 189 (Shenandoah: A Low-Pause-Time Garbage Collector (Experimental)), JEP 230 (Microbenchmark Suit), JEP 325 (Switch Expressions), JEP 334 (JVM Constants API), JEP 340 (One AArch64 Port, Not Two) und JEP 341 (Default CDS Archives), JEP 344 (Abortable Mixed Collections for G1), JEP 346 (Promptly Return Unused Committed Memory from G1).

JEP 189 – Shenandoah Garbage Collector (Experimental)

Shenandoah ist ein Garbage Collector für Java, der für seine sehr kurzen STW-Pausen bekannt ist. Entwickelt wurde der Collector von Red Hat, allerdings soll er nicht alle vorhandenen Alternativen verdrängen – trotz seiner Vorteile. Als Alternativen werden unter anderem Zing/Azul, ZGC, G1 und CMS genannt, wobei gerade der Vergleich von Shenandoah mit ZGC interessant sein dürfte. Das Feature wird zunächst experimentell zum JDK hinzugefügt.

JEP 230 – Microbenchmark Suite

Bislang ist die Microbenchmark Suite ein eigenständiges Projekt und wird auch als solches verwaltet. In JEP 230 wird vorgeschlagen, eine grundlegende Benchmark Suite direkt in den Source Code des JDKs zu implementieren. Damit sollen Entwickler, so das Ziel, einfacher existierende Microbenchmarks ausführen bzw. neue erstellen können. Basieren soll das Ganze auf dem Java Microbenchmark Harness, in diesem Fall sollen auch Updates des JMH unterstützt werden. Das ist gleichzeitig auch eines der Risiken: JDK Builds würden damit auf einer Version des JMH basieren. Problematisch für viele Nutzer könnte auch der vermutlich gravierende Anstieg der Build-Zeiten und der Größe des Quelltext-Repositorys werden. Dafür könnten Entwickler aber auf ein Set von etwa einhundert Benchmarks direkt zugreifen, die in der Suite integriert werden sollen.

JEP 325 – Switch Expressions

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

JEP 334 – JVM Constants API

JEP 334 beinhaltet ein neues API für das Erstellen nomineller Beschreibungen wichtiger Dateiklassen- und Laufzeit-Artefakte in Form von Konstanten, die aus einem Pool von Konstanten geladen werden. Dieses Sammelsurium wertbasierter symbolischer Referenztypen (JVMS 5.1) sollen im neuen Package java.lang.invoke.constant enthalten sein und die Beschreibung jeder ladbaren Konstante ermöglichen. Ursprünglich war das API eine Unterfunktion des JEP 303 (Intrinsics for the LDC and INVOKEDYNAMIC Instructions), sodass JEP 303 nun von JEP 334 abhängt.

JEP 340 – One AArch64 Port, Not Two

Das JEP 340 wurde erstellt, um sämtliche Sourcen zu entfernen, die mit dem arm64-Port zusammenhängen. Im JDK bleiben sollen allerdings der 32-bit ARM-Port und der 64-bit aarch64-Port. Entwickler, so verspricht man sich, brauchen sich dann nicht mehr mit zwei unterschiedlichen 64-bit ARM-Implementierungen herumschlagen. Zusätzlich fällt die Arbeit weg, gleich zwei dieser Ports verwalten und aktuell halten zu müssen.

JEP 341 – Default CDS Archives

Durch sogenanntes Class Data Sharing (CDS) kann die Startzeit von Java-Anwendungen reduziert werden, das gilt insbesondere für kleinere Anwendungen. Zudem hilft es dabei, den Footprint ein wenig zu verringern. Da man, um dieses Feature nutzen zu können, allerdings den befehl java -Xshare:dump ausführen muss, ist die Nutzung noch nicht allzu verbreitet. Durch das JEP 341 soll nun CDS mit der Standard-Klassenliste auch ohne diesen zusätzlichen Schritt automatisch für native 64-bit Builds genutzt werden. Die Unterstützung für 32-bit Builds und Cross-kompilierte Builds könnte in einem späteren Release hinzukommen.

JEP 344 – Abortable Mixed Collections for G1

JEP 344 sieht vor, den Garbace Collector G1 zu verbessern. Wählen die Auswahlheuristiken des Collection Sets immer wieder eine falsche Anzahl an Regionen aus, sollte das Collection Set zweigeteilt werden. Es sollte dann bestenfalls aus einem obligatorischen und einem optionalen Teil bestehen. Ersterer sollte dann aus den Teilen bestehen, die G1 nicht inkrementell verarbeiten kann (neue Regionen zum Beispiel), Letzterer sollte nur aus alten Regionen bestehen. Nach dem Pflichtteil wird dann der optionale Teil verarbeitet, G1 kann anschließend entscheiden, das Sammeln (basierend auf der verbleibenden Zeit) einzustellen. Wird die Garbage Collection dadurch wieder genauer, kann der optionale Teil schrumpfen, kommt es allerdings wieder zu Ungenauigkeiten, wird wieder gesplittet.

JEP 346 – Promptly Return Unused Committed Memory from G1

Um G1 geht es auch in JEP 346: In diesem Fall geht es darum, den G1 Garbace Collector insofern zu verbessern, dass der für den Java Heap reservierte Speicher wieder an das Betriebssystem übergeben wird, wenn G1 sich im Leerlauf befindet.

Weitere Informationen zu dem aktuellen Zeitplan für Java 12 gibt es auf der JDK-Dev Mailing-Liste, die finalen JEPs finden sich auf der Projektseite für das JDK 12.

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

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: