Das sind die neuen Features von Java 13

Inhaltsverzeichnis

Fast alle der ursprünglich für Java SE 13 geplanten Erweiterungen a.k.a. JEPs (JDK Enhancement Proposal) haben es durch die drei Phasen des JDK Release Process bis hin zum finalen Release geschafft und stehen dann heute im Laufe des Tages zum Download bereit.

Zu den neuen Features gehören dynamische CDS-Archive (JEP 350), ein überarbeiteter Z Garbage Collector (JEP 351), die Reimplementierung der in die Jahre gekommenen Socket API (JEP 353) sowie Previews für die Erweiterung der Switch-Anweisung (JEP 354) und die Unterstützung von Textblöcken (JEP 355). Lediglich das geplante Packaging Tool (JEP 343) blieb auf der Strecke und wird somit wohl erst im JDK 14 oder später zur Verfügung stehen.

JEP 350: Dynamic CDS Archives

Die Idee des Class Data Sharing existiert bereits seit Java 5. Das Konzept sieht vor, dass einmal geladene Klassen als Dump in einer Datei abgelegt und sich dann später bei einem erneuten Start der JVM als Memory Mapped File laden lassen. Das beschleunigt den Start der Anwendung um etliche Prozentpunkte. Dies gilt zumindest dann, wenn die Anwendung relativ klein ist und somit die Anzahl der genutzten Klassen des JDKs – denn nur diese werden beim ursprünglichen Class Data Sharing gespeichert und im Anschluss wiederverwendet – im Vergleich zu den eigenen Klassen relativ hoch ist.

Mit Java 8 wurde in der kommerziellen Java-Version, dem Oracle JDK, zusätzlich das Application Class Data Sharing eingeführt, das neben der Archivierung der genutzten JDK-Klassen die der eigenen Anwendungsklassen erlaubt. Je nach Art der eigenen Anwendung bringt das noch einmal eine Verbesserung der Startzeit der Anwendung mit sich sowie eine Optimierung des benötigten Speichers. Mit Java 10 hielt dieses Feature auch Einzug in das OpenJDK.

Mit dem JDK 13 wird das Konzept des Application Class Data Sharing noch einmal um die Möglichkeit zur dynamischen Archivierung erweitert. Während bisher die Archivierung explizit angestoßen werden musste, findet sie nun dank des neuen JEPs 350 automatisch bei der Beendigung der Anwendung statt. Berücksichtigt werden dabei alle Klassen und Bibliotheken, die nicht bereits Bestandteil des Standardarchivs (Base-Layer CDS Archive) sind.

Ziel dieser Erweiterung ist eine deutliche Vereinfachung der Nutzung des Application Class Data Sharing. Musste bisher zunächst mittels Trial-Run eine Klassenliste und im Anschluss das Archiv selbst auf Basis eben dieser Klassenliste manuell erzeugt werden, finden diese Schritte nun automatisch beziehungsweise dynamisch statt.

JEP 351: ZGC – Uncommit Unused Memory

Mit Java 11 wurde der Z Garbage Collector (ZGC) eingeführt, der deutlich geringere Latenz bei großen Heaps verursacht als die bis dato verfügbaren GCs. Leider bringt die Verwendung des ZGC aber auch einen kleinen, nicht zu vernachlässigen Nachteil mit sich. Ungenutzter beziehungsweise freigewordener Heap-Speicher wird zur Laufzeit einer Anwendung nicht wieder an das Betriebssystem zurückgegeben, sondern durch den ZGC zur Wiederverwendung blockiert. Steht ausreichend Speicher zur Verfügung – für genau diese Umgebungen ist der ZGC ursprünglich konzipiert – ist das nicht wirklich ein Problem. In Zeiten der Cloud (pay per use!) oder aber bei sehr ungleichmäßigem Heap-Speicherbedarf einer Anwendung während ihrer Laufzeit ist das Verhalten allerdings alles andere als optimal.

Genau an dieser Stelle setzt die Verbesserung im JDK 13 an. Mittels individuell auf die Anwendung abstimmbaren Timeout lässt sich angeben, nach welcher Zeit ungenutzte ZPages durch den ZGC freigeben (a.k.a. uncommited) werden sollen. Das Feature ist im JDK 13 automatisch aktiviert und mit einem Standardwert hinterlegt. Er kann bei Bedarf durch die Command-Line-Option XX:ZUncommitDelay=<seconds> überschrieben und so individuell an die Bedürfnisse der Anwendung angepasst werden.

Für die Zukunft sind neben der Verwendung des Standardwertes deutlich ausgereiftere Strategien geplant, die zum Beispiel auf Basis von Heuristiken ein optimales Timeout berechnen und so die Command-Line-Option überflüssig werden lassen.

JEP 353: Reimplement the Legacy Socket API

Die bereits seit dem JDK 1.0 existierenden Implementierungen der java.net.Socket- und java.net.ServerSocket-APIs sind mittlerweile in die Jahre gekommen und nicht mehr zeitgemäß. Die bisherigen Implementierungen beruhten auf einem Mix aus altem Java- und C-Code und sind faktisch kaum noch zu warten beziehungsweise zu debuggen.

Mit dem JDK 13 steht nun eine zeitgemäße, vollständige Neuimplementierung der beiden APIs zur Verfügung, die auf der New I/O aufsetzt und unter anderem die bisherige PlainSocketImpl durch eine NioSocketImpl ersetzt. Durch diesen Schritt sollen die APIs wartbarer gemacht und für zukünftige Anpassungen und Erweiterungen gerüstet werden, wie sie zum Beispiel für die Adaption an die Anforderungen von User-Threads (Fibers) des Projekts Loom notwendig werden.

JEP 354: Switch Expressions (Preview)

Die in JDK 13 hinzugekommene Vorschau der Switch Expressions ersetzt den gleichnamigen JEP 325 aus JDK 12. Der neue JEP 354 hat sich zum Ziel gesetzt, die tägliche Arbeit der Entwickler zu vereinfachen. Switch-Anweisungen können zukünftig sowohl als Statement als auch als Expression genutzt werden und somit explizit einen Wert zurückliefern. Das Ergebnis einer Switch-Anweisung vom Typ Expression kann somit zum Beispiel einer Variablen zugeordnet werden. Neben dem traditionellen Kontrollfluss kann nun alternativ auch eine stark vereinfachte Variante gewählt werden. Die Switch-Anweisung wird so deutlich schlanker und lesbarer.

Bei der vereinfachten Variante ist zum Beispiel die Verwendung mehrerer, kommaseparierter Labels in einer case-Zeile erlaubt. Und auch auf das break-Statement kann in bestimmten Situationen verzichtet werden. Das folgende Beispiel zeigt eine switch-Anweisung als Expression inklusive vereinfachtem Kontrollfluss und der Verwendung mehrfacher Labels:

int numLetters = switch (day) {
    case MONDAY, FRIDAY, SUNDAY -> 6;
    case TUESDAY                -> 7;
    case THURSDAY, SATURDAY     -> 8;
    case WEDNESDAY              -> 9;

Neu ist ebenfalls das Keyword yield, mit dessen Hilfe der Rückgabewert einer switch-Anweisung vom Typ Expression in einem komplexeren Block definiert werden kann:

int j = switch (day) {
    case MONDAY  -> 0;
    case TUESDAY -> 1;
    default      -> {
        int k = day.toString().length();
        int result = f(k);
        yield result;
    }
};

JEP 355: Text Blocks (Preview)

Bereits im JDK 12 gab es die Diskussion, Java um die sogenannten Raw String Literals (JEP 326) zu erweitern. Die Idee dabei war, dass sich Strings über mehrere Zeilen erstrecken können und Escape-Zeichen nicht interpretiert werden sollten. Die erzeugten Strings würden also die "rohen" Daten übernehmen.

Die neu in JDK 13 eingeführten Text Blocks ersetzen beziehungsweise erweitern die Idee der Raw String Literals, was zur Folge hat, dass der JEP 326 aufgegeben wurde.

Auch Text Blocks erlauben mehrzeilige Strings. Entwickler können dabei dank einer automatischen Formatierung auf die meisten der sonst notwendigen Escape-Sequenzen verzichten. Das erhöht vor allem die Lesbarkeit bei der Einbindung von Code anderer Sprachen wie HTML, XML, SQL oder JSON in Strings:

String html = """
              <html>
                  <body>
                      <p>Hello, world</p>
                  </body>
              </html>
              """;

Wenn notwendig kann die Formatierung den eigenen Bedürfnissen angepasst und so die automatische Formatierung überschrieben werden.

Fazit

Die neuen Features des JDK 13 stellen sicherlich keine Revolution dar, aber immerhin eine Evolution. Und genau das ist auch der Plan. Anstatt alle zwei bis drei Jahre (zwischen J2SE 5 und Java SE 6 waren es sogar fast fünf Jahre) ein Monster-Release anzukündigen, das am Ende die hochgesteckten Erwartungen nur selten erfüllen konnte, gibt es mittlerweile verlässlich alle sechs Monate eine neue Version des JDKs.

Wie auch schon in den Versionen zuvor, ist das neue JDK wieder ein guter Mix aus internen Optimierungen und neuen APIs, die die tägliche Arbeit des Entwicklers erleichtern.

Wer sich für die zu erwartenden Features des Folgereleases – JDK 14 – interessiert, dem sei ein regelmäßiger Blick auf die zugehörige Webseite empfohlen.

Lars Röwekamp
ist Gründer des IT-Beratungs- und Entwicklungsunternehmens open knowledge und beschäftigt sich im Rahmen seiner Tätigkeit als "CIO New Technologies" mit der eingehenden Analyse und Bewertung neuer Software- und Technologietrends. (ane)