7+7

Java 14: Das JDK ist in der Rampdown-Phase

Dominik Mohilo

© Shutterstock / Oleksandr Kostiuchenko

Mit Java 14 ist die dritte Version seit dem letzten Release mit Long-Term-Support in Arbeit. Java 12 und Java 13 wurden bzw. werden mit einer recht überschaubaren Anzahl an neuen Features ausgeliefert, für Java 14 wird sich dieses Schema aller Voraussicht nach ein wenig ändern. Trotz der neuen Veröffentlichungskadenz sind insgesamt 16 JEPs auf dem Weg ins JDK, unter anderem eine überarbeitete Version der Text Blocks und das Pattern Matching für instanceof. Nun hat die Rampdown-Phase begonnen.

Ob wir in Java 15 wohl mehr Features aus Projekt Valhalla oder Projekt Amber sehen werden? Das steht noch in den Sternen. Auch ob Git, wie in Projekt Skara noch geprüft wird, Mercurial für das JDK ersetzt ist noch nicht abschließend entschieden, es sieht aber fast danach aus, entsprechende JEPs gibt es bereits.

Die Migration zu Git wird wohl noch ein wenig warten müssen, Mercurial bleibt also zumindest bis Java 15 noch das Versionskontrollsystem der Wahl. Sicher sein können wir uns diesbezüglich, da die erste Rampdown-Phase begonnen hat und damit keine neuen Features mehr in das aktuelle JDK Einzug halten werden.

JDK 14: So lief es ab

Der erste Schritt auf dem Weg zum nächsten Java Release wurde im Juni gemacht, zu diesem Zeitpunkt wurde die Expert Group formiert. Teil dieser sind Simon Ritter (Azul Systems), Manoj Palat (Eclipse Foundation), Tim Ellison (IBM), Andrew Haley (Red Hat), Volker Simonis (SAP SE), Iris Clark (Oracle) und natürlich Brian Goetz (ebenfalls Oracle).

Die Release Schedule

Wie gewohnt hat Mark Reinhold auf der jdk-dev Mailing-Liste die geplante Release Schedule veröffentlicht. Dies ist, da keine Einsprüche erhoben worden sind, der finale Plan. So sieht also die Release Schedule für Java 14 aus:

Datum Ereignis
12. Dezember 2019 Start Rampdown-Phase Eins
16. Januar 2020 Start Rampdown-Phase Zwei
06. Februar 2020 Veröffentlichung initialer Release Candidate
20. Februar 2020 Veröffentlichung finaler Release Candidate
17. März 2020 Veröffentlichung Java 14

Zudem haben Entwickler bereits die Möglichkeit, wie man auch auf Twitter lesen kann, Early Access Builds auszuprobieren. Der aktuellste ist vom 9. Dezember 2019:

JDK 14: Das sind die neuen Features

Proposals kann es viele geben, Drafts noch viel mehr, doch welche Features ernsthaft für eine Veröffentlichung in einem bestimmten JDK vorgesehen sind, erhalten das Tag „Targeted“. Ganze 16 JEPs sind definitiv für Java 14 vorgesehen. Und hier sind die finalen Features, die aller Voraussicht nach im neuen JDK enthalten sein werden:

JEP 305 – Pattern Matching for instanceof (Preview)

Im Zuge des Projektes Amber wird unter anderem am sogenannten Pattern Matching für Java gearbeitet. Für den Operator instanceof könnte das Pattern Matching in Java 14 Wirklichkeit werden. Durch Pattern Matching soll die Programmiersprache Java prägnanter und sicherer werden. Die „Form“ von Objekten kann so präzise definiert werden, woraufhin diese dann von Statements und Expressions gegen den eigenen Input getestet werden. Die Nutzung von Pattern Matching in instanceof könnte für einen starken Rückgang nötiger Typumwandlungen in Java-Anwendungen sorgen. In zukünftigen Java-Versionen könnte dann Pattern Matching für weitere Sprachkonstrukte wie Switch Expressions kommen.

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 345 – NUMA-Aware Memory Allocation for G1

Mehrkernprozessoren sind mittlerweile der allgemeine Standard. In einer NUMA-Arbeitsspeicher-Architektur erhält jeder Kern des Prizessors einen lokalen Arbeitsspeicher, auf den die anderen Kerne allerdings Zugriff gewährt wird. JEP 345 sieht vor, den G1 Garbage Collector mit der Möglichkeit auszustatten, solche Architekturen vorteilhaft zu nutzen. Damit soll unter anderem die Performance auf sehr leistungsstarken Maschinen erhöht werden. Das JEP 345 dient dabei ausschließlich für die Implementierung des NUMA-Supports für den G1 Garbage Collector, nur für das Speichermanagement (Memory Allocation) und auch nur unter Linux. Ob also diese Unterstützung von NUMA-Architekturen auch für andere Garbage Collectors kommt oder für andere Teile wie etwa das Task Queue Stealing kommt, ist nicht bekannt.

JEP 349 – JFR Event Streaming

Der Java Flight Recorder (JFR) ist mittlerweile Teil des OpenJDKs und damit frei verfügbar. Mit JEP 349 wird vorgeschlagen, ein API zu erstellen, über das die vom Java Flight Recorder erhobenen Daten für die kontinuierliche Überwachung von aktiven und inaktiven Anwendungen genutzt werden können. Dabei sollen die gleichen Events aufgenommen werden, wie bei der nicht-streaming-Variante, der Overhead soll weniger als 1 Prozent betragen. Event Streaming würde so mit der nicht-streaming-Variante gleichzeitig durchgeführt werden. JEP 349 soll allerdings keine snychronen Callbacks für den jeweiligen Konsumenten ermöglichen, auch Daten aus Recordings, die im Zwischenpeicher liegen sollen nicht verfügbar gemacht werden. Technisch würde das Package jdk.jfr.consumer im Modul jdk.jfr durch die Funktionalität erweitert werden, asynchron auf Events zugreifen zu können.

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.

JEP 358 – Helpful NullPointerExceptions

Programme, und da machen auch Java-Anwendungen keine Ausnahme, bestehen in der Regel aus einer Vielzahl an Methoden, Objekten, Funktionen, Annotationen und so weiter. Und in diesem großen Sammelsurium aus Kleinteilen kann praktisch überall eine sogenannte NullPointerException (NPE) auftreten. Dieses Problem soll von JEP 358 gelöst werden. Durch eine Analyse der Bytecode-Anweisungen eines Programms soll die JVM zukünftig präzise aufzeigen können, welche Variable einen Nullwert ergibt. Daraufhin soll die JVM eine null-detail message in der NullPointerException ausgeben, die neben der bislang üblichen Meldung erscheint. Das obige Beispiel würde dann wie folgt aussehen:

Exception in thread "main" java.lang.NullPointerException: 
        Cannot assign field 'i' because 'a' is null.
    at Prog.main(Prog.java:5)

Entsprechend würde die Nachricht für das etwas komplexere Beispiel (a.b.c.i = 99;) so erscheinen:

Exception in thread "main" java.lang.NullPointerException: 
        Cannot read field 'c' because 'a.b' is null.
    at Prog.main(Prog.java:5)

Ziel des JEP 358 ist es, so die Autoren, Entwicklern wichtige und hilfreiche Informationen für die Fehlerbehebung direkt an die Hand zu geben. Neue Entwickler wären so weniger verwirrt und besorgt über NPEs und das allgemeine Verständnis eines Programms könnte so auch verbessert werden.

JEP 359 – Records (Preview)

JEP 359 bringt Records als Preview-Feature für Java. Bei Records handelt es sich um einen neuen Typ, der im Zuge des Projektes Valhalla entwickelt wurde. Diese stellen – wie beispielsweise auch enums – eine eingeschränkte Form der Deklaration class dar. Records unterscheiden sich von klassischen Klassen darin, dass sie ihr API nicht von dessen Repräsentation entkoppeln können. Die Freiheit die dabei verloren geht, wird aber durch die gewonnene Präzision wettgemacht.

Im Proposal zu den Records hieß es dazu, dass ein Record „der Zustand, der gesamte Zustand und nichts als der Zustand“ sei. Er besteht aus einem Namen, der Statusbeschreibung und dem Body:

record Point(int x, int y) { }

Records bleiben dabei Klassen, auch wenn sie eingeschränkt sind. So können sie etwa Annotationen oder Javadocs enthalten und deren Body u.a. statische Felder sowie Methoden, Konstruktoren oder Instanzmethoden deklarieren. Was sie allerdings nicht vermögen, ist die Erweiterung anderer Klassen oder die Deklaration von Instanzfeldern (mit der Ausnahme der Statuskomponenten, die im Header des Records deklariert wurden).

JEP 361 – Switch Expresisons (Standard)

In unserem Experten-Check zu Java 14 haben wir sieben Experten nach ihren Wünschen für die kommende Java-Version gefragt. Der Wunsch, dass die bisher nur als „Preview Feature“ verfügbaren Switch Expressions den GA-Status erreichen (und neben ihnen auch die Text Blocks), wurde mehrfach gesagt.

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 wurde 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 blieben die Switch Expressions unverändert und sollen nun in diesem Status Teil einer der nächsten Java-Versionen werden – vielleicht sogar schon Teil von Java 14. Eine kleine Einführung in das Thema hat Michael Inden in seinem Artikel auf JAXenter gegeben.

JEP 362 – Deprecate the Solaris and SPARC Ports

Das Betriebssystem Solaris stammt noch aus den Beständen von Sun Microsystems und ist mittlerweile nicht mehr wirklich zeitgemäß. Entsprechend wenig überraschend ist daher der Wunsch von Oracle, die Ports für Solaris/SPARC, Solaris/x64 und Linux/SPARC als deprecated zu markieren. Der nächste Schritt ist dann laut JEP 362, sie in einem zukünftigen Update endgültig loszuwerden. Es sei allerdings angemerkt, dass alte Java-Versionen (bis JDK 14) auf alten Systemen allerdings unverändert laufen sollen, inklusive der entsprechenden Ports.

Ziel des Ganzen ist es, sich um andere Features kümmern zu können. Sollte sich allerdings doch eine Gruppe engagierter und interessierter Entwickler finden, die die Ports betreuen und verwalten wollen, könnte die Entfernung aus dem JDK allerdings auch zu einem späteren Zeitpunkt noch gekippt werden.

JEP 363 – Remove the Concurrent Mark Sweep (CMS) Garbage Collector

Nun ein offizielles JEP (363) ist eine von Thomas Schatzl vorgeschlagene Änderung: Der Concurrent Mark Sweep (CMS) Garbage Collector soll, nachdem er bereits in Java 9 (JEP 291) als veraltet markiert worden ist. Zwei Jahre hatten, so Schatzl, interessierte User Zeit, sich des Projektes anzunehmen. Da dies bislang nicht der Fall war, soll nun die letzte Reise für Mark Sweep vorbereitet werden.

Nutzer älterer Java-Versionen, die auf den CMS GC setzen, können aber beruhigt aufatmen: Es ist nicht Ziel, den Garbage Collector aus früheren Releases des JDKs zu entfernen. Gleiches gilt, auch wenn dies eigentlich nicht erwähnt werden muss, für andere Müllsammler wie Shenendoah oder ZGC. Diese bleiben im JDK enthalten und haben mit dem neuen JEP Draft nichts zu tun.

JEP 364 – ZGC on macOS

Auch JEP 364 befasst sich mit der Garbage Collection und wurde von Erik Österlund erstellt. Ziel des Proposals ist es, den Z Garbage Collector auch für macOS-Nutzer als Option zur Verfügung zu stellen. Teil des JEPs soll gleichzeitig auch die Funktionalität des Collectors sein, ungenutzten Speicher für das System wieder freizugeben, wie es in JEP 351 vorgeschlagen wurde. Diese Funktionalität ist seit Java 13 im JDK enthalten.

JEP 365 – ZGC on Windows

JEP 365 ist praktisch der gleiche Vorschlag, wie JEP 364. Der einzige Unterschied ist, bei JEP 365 geht es um die Bereitstellung des Z Garbage Collectors (ZGC) für Windows. Der Großteil der Code-Basis des ZGC ist plattformunabhängig, es sollte also nur ein geringer Entwicklungsaufwand sein, ihn auch für Windows fit zu machen. Einschränkungen gibt es bei der Kompatibilität zu älteren Windows-Versionen: Windows 10 und Windows Server sollten nicht älter als Version 1803 sein, da ältere Versionen nicht das benötigte API für Speicherreservierungen beinhalten.

JEP 366 – Deprecate the ParallelScavenge + SerialOld GC Combination

Auch in JEP 366 geht es um die Garbage Collectoren, bzw. in diesem Fall um eine Kombination aus zwei „Müllsammlern“: ParallelScavenge und SerialOld. Der Vorschlag ist, die Kombination der Algorithmen der beiden als Deprecated zu markieren, da wohl nur sehr weniger Entwickler sie in dieser Form einsetzen. Am Ende geht es hier um den Kosten-Nutzen-Faktor, denn diese Kombination aktuell zu halten erfordert einen erheblichen Aufwand, bedenkt man die Seltenheit der tatsächlichen Nutzung. Komplett ausgebaut soll die Kombination, die via -XX:UseParallelGC und -XX:-UseParallelOldGC aufgerufen wird, allerdings nicht werden. Der Garbage Collector Parallel ist allerdings in Augen von Thomas Schatzl, der dieses JEP vorgeschlagen hat, eine gute Alternative.

JEP 367 – Remove the Pack200 Tools and API

Das Kompressionsshema Pack200, das für die Komprimierung von JAR-Dateien genutzt wird, ist bereits seit Java 11 als veraltet markiert. JEP 367 ist nun das offizielle Proposal, um die Tools pack200 und unpack200 sowie das Pack200 API aus dem Package java.util.jar zu entfernen. Die Technik ist seinerzeit in Java 5 eingeführt worden und diente als Reaktion auf die damals noch sehr begrenzte Bandbreite (56k Modems) und den geringen Speicherplatz auf Festplatten. Mit Java 9 wurden bereits vor einiger Zeit neue Kompressionsschemata eingeführt, Entwicklern wird empfohlen, jlink zu nutzen.

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

JEP 368 – Text Blocks (Second Preview)

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.

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

JEP 368 stellt nun die zweite Preview dar. Basierend auf dem Feedback wurden zwei neue Escape-Sequenzen dem Feature hinzugefügt, 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.

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. Einen offiziellen Guide von Oracle zu Text Blocks finden unsere Leser hier auf JAXenter.

JEP 370: Foreign-Memory Access API (Incubator)

Es gibt tonnenweise Java-Bibliotheken und auch -Anwendungen, die auf fremden Speicher zugreifen. Prominente Beispiele sind Ignite, mapDB, memchaced oder Nettys ByteBuf API. Dennoch stellt das Java API selbst keine gute Möglichkeit hierfür zur Verfügung – und das obwohl dadurch Kosten in Sachen Garbage Collection (besonders bei der Verwaltung großen Caches) gespart und Speicher über mehrere Prozesse hinweg geteilt werden kann. Auch das Serialisieren und Deserialisieren von Speicherinhalten via Mappings von Dateien in den Speichern wird durch den Zugriff auf fremden Speicher möglich (etwa via mmap).

Mit JEP 370 soll ein passendes Java API ins JDK implementiert werden, mit dem Java-Anwendungen sicher und effizient auf fremden Speicher zugreifen lässt, der außerhalb des Java Heaps angesiedelt ist. Wichtig sind die drei Prämissen: Allgemeingültigkeit, Sicherheit und Determinismus.

Ersteres bedeutet, dass ein einziges API in Verbindung mit unterschiedlichen fremden Speichern arbeiten sollte (gemeint sind nativer Speicher, persistenter Speicher etc.). Die Sicherheit der JVM ist das höchste Gut, daher sollte das API nicht dazu fähig sein, diese zu unterwandern – völlig egal, welcher Speicher zum Einsatz kommt. Zudem (Determinismus) sollte die Freigabe von Speicher explizit im Quelltext erfolgen.

Dieses Jep wurde im Zuge des Project Panama entwickelt und stellt eine klare Alternative zur Verwendung von existierenden APIs wie ByteBuffer, Unsafe oder JNI dar. Natürlich hilft die Implementierung bei der Erreichung der generellen Maxime des Projektes: der Unterstützung von nativer Interoperabilität von Java.

Mögliche Features & Veränderungen für Java 15

Wie immer sind Angaben ohne Gewähr. Dennoch gibt es bereits einige Features, die möglicherweise in Java 15 oder in späteren Versionen auftauchen werden.

Migration zu Git & GitHub

Wie oben bereits erwähnt, wird aller Voraussicht nach Git in Verbindung mit GitHub die neue Versionskontrolle bzw. Hosting-Plattform für Java. In JEP 357 steht die Migration auf Git zur Prüfung bereit, https://openjdk.java.net/jeps/369>JEP 369 beschäftigt sich hingegen mit dem Umzug auf GitHub.

JEP 369: GitHub wird designierte Hosting-Plattform für Java

Preview APIs

Alle Features, die für die Programmiersprache Java vorgeschlagen werden, müssen ausgiebig getestet werden. Hierfür können Entwickler optional die Verwendung dieser Features aktivieren (Preview Features). Manche dieser Features haben Abhängigkeiten zu APIs, die im Namespace java.* hinterlegt sind. Sind die Preview Features aktiviert, dann gibt es keine bösen Überraschungen. Sollte dies nicht der Fall sein und die APIs werden dennoch aufgerufen, kann es zu Problemen führen, denn die Warnungen, die vom Compiler zur Zeit der Kompilierung ausgegeben werden, haben praktisch keinen Bezug zu den Preview Features. Außerdem können die Warnungen im Code unterdrückt werden.

Abhilfe soll hier die von Joe Darcy vorgeschlagene Funktionalität der Preview APIs schaffen. So sollen zu Preview Features gehörige APIs zukünftig explizit ausgezeichnet werden (etwa java.lang.annotation.PreviewFeature), sodass sie zur Kompilierzeit vom Compiler registriert werden und entsprechende Fehlermeldungen ausgegeben werden, falls Preview Features nicht aktiviert sind. Alex Buckley führt dazu aus:

To be clear: this proposal means there will be APIs in the Java SE Platform that can only be used when preview features are enabled — just as there are already language features in the Platform that can only be used when preview features are enabled.

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.

Zudem wurde ein neues Projekt ins Leben gerufen, Project Lanai, bei dem es um eine neue 2D-Rendering-Pipeline für das JDK und OpenJFX für macOS geht.

Weitere Informationen zum Status Quo von Java 14 gibt es auf der offiziellen Projektseite von OpenJDK, Informationen zur Expertengruppe und weitere Links finden sich hier. Mehr zu den Early Access Builds finden Sie auf der entsprechenden Homepage.

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

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

1 Kommentar auf "Java 14: Das JDK ist in der Rampdown-Phase"

avatar
4000
  Subscribe  
Benachrichtige mich zu:
Entwickler
Gast

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