On the road again

Java 15: Der voraussichtliche Zeitplan und die ersten JEPs sind da

Dominik Mohilo

© Software & Support Media GmbH / Bianca Röder

 

Gerade ist Java 14 erschienen, doch der Motor steht nicht still: Es wird bereits sehr fleißig an Java 15 gearbeitet. Wann wir die Früchte dessen sehen können? Darauf gibt die vorgeschlagene Release Schedule Auskunft, die gerade veröffentlicht wurde. Und die ersten für das JDK 15 vorgeschlagenen JEPs sind ebenfalls bereits bekannt (Spoiler Alert: Bye, Nashorn)…

Neues Spiel, neues Glück: Auf Java 14 folgt – erwartungsgemäß – Java 15. Ob das Update mehr Features aus Projekt Valhalla oder Projekt Amber bringen wird? Unsere Leser würden es sich wünschen, wie ein Kommentar zeigt:

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üsste in den meisten Fällen kein asynchroner Code mehr geschrieben werden. Endlich wieder synchron, blockierend und ohne die üblichen Nachteile.

Die Migration zu Git, die im Zuge von Projekt Skara geprüft wurde, könnte ebenfalls Teil von Java 15 werden – es könnte sein, dass wir Java dann offiziell im Herbst auf GitHub sehen. Die JEPs für die Migration von Mercurial auf Git und in Konseqenz dann auf GitHub stehen jedenmalls bereits zur Diskussion und könnten bald Teil des aktuellen Release-Zyklus‘ werden: JEP 357: Migrate from Mercurial to Git & JEP 369: Migrate to GitHub.

Java 15: Die Release Schedule

Auch wenn viele Dinge sich ändern, manches bleibt unverrückbar bestehen: Die Release Schedule für Java etwa. Wie immer gibt es zwei Rampdown-Phasen gefolgt von zwei RC-Phasen und dem Release. Wie immer hat Mark Reinhold von Oracle den Zeitplan für Java 15 auf der jdk-dev-Mailing-Liste geteilt. Bis 2. April um 23 Uhr kann dagegen noch Einspruch erhoben werden. Sollte keiner kommen, wird Java 15 wohl am 15. September 2020 erscheinen. Ein passendes Datum.

Datum Phase
11. Juni 2020 Rampdown-Phase 1
16. Juli 2020 Rampdown-Phase 2
06. August 2020 Erster Release Candidate
20. August 2020 Finaler Release Candidate
15. September 2020 Veröffentlichung von Java 15

Wie immer wurde bereits Frühzeitig die Expertengruppe für das aktuelle Release gegründet, diese besteht diesmal aus Simon Ritter (Azul Systems), Manoj Palat (Eclipse Foundation), Tim Ellison (IBM), Andrew Haley (Red Hat), Christoph Langer (SAP SE), Iris Clark (Oracle) and Brian Goetz (Oracle).

JDK 15: Diese JEPs sind Teil des Releases

Vorweg sei natürlich wie immer angemerkt, dass die Vorschläge und JEPs nur eben das sind, was der Name schon sagt: Proposals, also Vorschläge. Ob diese wirklich Einzug ins JDK halten und somit Java 15 ausmachen, das ist aktuell noch nicht abzusehen und wird sich erst im Laufe der Rampdown- und RC-Phasen herauskristallisieren. Dennoch zeigte die Vergangenheit, dass die meisten JEPs, die während der Entwicklungsphase für ein Release vorgemerkt wurden, schließlich auch darin enthalten waren.

JEP 372 – Remove the Nashorn JavaScript Engine

Auf der Jagd nach dem heiligen Gra(a)l gab es so manchen Schwund. Ein solcher wird die JavaScript-Engine Nashorn sein, wie in JEP 372 – Remove the Nashorn JavaScript Engine von Jim Laskey vorgeschlagen wird. Bereits 2018 wurde der Grundstein für den Ausbau der Nashorn-Engine, der entsprechenden APIs und der JJS Tools gelegt, in Java 11 wurden sie als deprecated markiert. Damit hatte die ursprünglich in JDK 8 via JEP 174 eingeführte Script-Engine keine besonders lange Halbwertszeit, auch wenn sie damals die eher antiquierte Rhino-Engine ersetzte.

Der Teufel liegt bei der Intention, das Nashorn loszuwerden, natürlich in der Zeit: JavaScript und der ECMA-Standard entwickeln sich rapide weiter und die Engine im JDK auf Stand zu halten ist gelinde gesagt herausfordernd, wie das Nashorn-Team im JEP schreibt. Da sich wohl auch die breitere Community nicht wirklich bewegt hat, um das Nashorn zu pflegen, bleibt nun nur der Schritt nach vorne, also die JavaScript-Engine in den verdienten Ruhestand zu schicken. Keinen Einfluss hat dieses JEP übrigens auf das API javax.script, dieses soll unverändert bleiben.

Entfernt werden allerdings die Module jdk.scripting.nashorn und jdk.scripting.nashorn.shell, wie Jim Laskey schreibt. Ersteres enthält die Packages jdk.nashorn.api.scripting und jdk.nashorn.api.tree, Letzteres die JJS Tools.

JEP 377: ZGC: A Scalable Low-Latency Garbage Collector (Production)

Mit diesem JEP wird vorgeschlagen, den Z Gargabe Collector aus dem experimentellen Status zu entheben und ihn zu einem festen Bestandteil des JDKs zu machen. Dabei soll der Standard allerdings nicht verändert werden: der G1 Garbage Collector bleibt auch weiterhin der standardmäßig genutzte GC in Java 15. Der ZGC ist bereits seit Java 11 Bestandteil des JDKs und wurde mit JEP 333 in das System eingeführt. Nach etlichen Tests und Bugfixes soll er nun bereit für die Produktion sein.

JEP 378: Text Blocks (Standard)

In Java 13 war JEP 355 als Preview-Feature enthalten, mit dem der neue Typ Text Block eingeführt werden sollte. Die Bemühungen des JEPs basierten auf den Grundlagen, die bereits für JEP 326 und die Raw String Literals geschaffen wurden. Die im Vorschlag beschriebenen Textblöcke sollen mehrzeilige String-Literale darstellen. Ihre Formatierung unterliegt einheitlichen Regeln und orientiert sich an der Darstellung des Texts im Quellcode, sodass Entwickler nicht zwingend auf Befehle zurückgreifen müssen, um das Layout des Texts zu beeinflussen. Den kompletten Style Guide zu Text Blocks haben Jim Laskey und Stuart Marks verfasst und er ist auf JAXenter zu finden, In seinem Artikel „Textblöcke in Java 13: Warum sich das lange Warten gelohnt hat“ geht Tim Zöller auf das Feature genauer ein.

Lesen Sie auch: Java Tutorial: Eine Einführung in Text Blocks und offizieller Style Guide

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. JEP 368, enthalten in Java 14, brachte, basierend auf Nutzer-Feedback, zwei neue Escape-Sequenzen für dieses Feature, die eine feingranulare Kontrolle der Verarbeitung von Newlines und Whitespaces erlauben: \<line-terminator> und \s. Erstere Escape-Sequenz kann genutzt werden, um einen Umbruch für sehr lange String-Literale zu forcieren, ohne diese in kleinere „Substrings“ aufzuteilen.

Nun folgt mit JEP 378: Text Blocks (Standard) die offizielle Einführung als Standard in Java 15. Technisch sieht das Feature wie folgt aus:

Ohne \<line-terminator> Escape-Sequenz:

String literal = "Lorem ipsum dolor sit amet, consectetur adipiscing " +
                 "elit, sed do eiusmod tempor incididunt ut labore " +
                 "et dolore magna aliqua.";

Mit \<line-terminator> Escape-Sequenz:

String text = """
                Lorem ipsum dolor sit amet, consectetur adipiscing \
                elit, sed do eiusmod tempor incididunt ut labore \
                et dolore magna aliqua.\
                """;

Die Escape-Sequenz \s lässt sich einfach als einzelnes Leerzeichen (\u0020) beschreiben. Damit lässt sich im unteren Beispiel sicherstellen, dass die Zeilen exakt 6 Stellen haben und nicht länger sind:

String colors = """
    red  \s
    green\s
    blue \s
    """;

Diese Escape-Sequenz kann in den neuen Text Blocks, aber auch in klassischen String-Literalen genutzt werden.

JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector (Production)

Wie JEP 377 geht es in JEP 379 ebenfalls um einen Garbage Collector, in diesem Fall den Shenandoah GC. Auch dieser soll endlich den experimentellen Status verlassen und fester Bestandteil von Java 15 werden – und wie ZGC soll auch Shenandoah nicht den Standard Garbage Collector von Java ersetzt. Bereits 2014 wurde mit JEP 189 der Shenandoah GC als experimentelles Feature für Java vorgeschlagen, doch erst mit JDK 12 wurde er tatsächlich in Java integriert.

Weitere Informationen zu Java 15 und den entsprechenden JEPs gibt es einerseits auf der Seite für das JDK und in den einzelnen JEPs.

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

avatar
4000
  Subscribe  
Benachrichtige mich zu: