© S&SMedia/Bianca Röder, © pathdoc/Shutterstock.com
Java geht in die nächste Runde

Die Neuerungen des OpenJDK 15


Mit Java 15 erscheint nun bereits das sechste halbjährliche Java-Release in Folge. Und das mal wieder genau im Zeitplan – eine Eigenschaft, die man von IT-Projekten im Allgemeinen und früheren Java-Versionen im Speziellen so nicht gewohnt ist. Laut der Ankündigung auf der Mailingliste [1] gibt es neben Hunderten kleineren Verbesserungen und Tausenden Bugfixes insgesamt vierzehn neue Features. In diesem Artikel werfen wir einen Blick auf die relevanten Änderungen.

Die wichtigsten neuen Funktionen wurden wieder in Form von Java Enhancement Proposals (JEP) entwickelt. Eine Auflistung inklusive Verlinkungen zu den einzelnen Projektseiten findet sich auf der Webseite des OpenJDK [2].

  • 339: Edwards-Curve Digital Signature Algorithm (EdDSA)

  • 360: Sealed Classes (Preview)

  • 371: Hidden Classes

  • 372: Remove the Nashorn JavaScript Engine

  • 373: Reimplement the Legacy DatagramSocket API

  • 374: Disable and Deprecate Biased Locking

  • 375: Pattern Matching for instanceof (Second Preview)

  • 377: ZGC: A Scalable Low-Latency Garbage Collector

  • 378: Text Blocks

  • 379: Shenandoah: A Low-Pause-Time Garbage Collector

  • 381: Remove the Solaris and SPARC Ports

  • 383: Foreign-Memory Access API (Second Incubator)

  • 384: Records (Second Preview)

  • 385: Deprecate RMI Activation for Removal

Einige der Features befinden sich noch im Preview- oder Inkubator-Modus. Die Macher des OpenJDKs wollen ihre Ideen so möglichst frühzeitig vorzeigen und erhoffen sich Feedback aus der Community. Diese Rückmeldungen fließen dann bereits in die nächsten halbjährlichen Releases ein. Wir Java-Entwickler können zudem regelmäßig neue Sprachfunktionen und JDK-Erweiterungen ausprobieren. Spätestens zur nächsten LTS-(Long-Term-Support-)Version erfolgt dann die Finalisierung der Previews. Das wird übrigens das OpenJDK 17 sein, das für September 2021 geplant ist.

Auf JAXenter [3] gibt es bereits einen kompakten Überblick über alle Änderungen des JDK 15. Wir wollen in diesem Artikel etwas tiefer auf die vor allem für Entwickler relevanten Themen schauen. Und da sind die Sealed Classes (JEP 360) die vermutlich interessanteste Neuerung. Dieses Feature wurde im Rahmen von Projekt Amber entwickelt.

Sealed Classes gehören zu einer Reihe von vorbereitenden Maßnahmen für die Umsetzung von Pattern Matching in Java. Ganz konkret sollen sie bei der Analyse von Mustern unterstützen. Aber auch für Framework-Entwickler bieten sie einen interessanten Mehrwert. Die Idee hinter Sealed Classes ist, dass versiegelte Klassen und Interfaces entscheiden können, welche Subklassen oder -Interfaces von ihnen abgeleitet werden dürfen.

Bisher konnte man als Entwickler Ableitung von Klassen nur durch Zugriffsmodifikatoren (private, protected, ...) einschränken oder durch die Deklaration der Klasse als final komplett durch den Compiler untersagen. Sealed Classes bieten aber nun einen deklarativen Weg, um nur bestimmten Subklassen die Ableitung zu erlauben. Hier zur Verdeutlichung ein kleines Beispiel:

public sealed class Vehicle permits Car, Bike, Bus, Train { }

Vehicle darf nur von den vier genannten Klassen überschrieben werden. Damit wird auch dem Aufrufer deutlich gemacht, welche Subklassen erlaubt sind und damit überhaupt existieren. Subklassen bergen zudem immer die Gefahr, dass beim Überschreiben der Vertrag der Superklasse verletzt wird. Zum Beispiel ist es unmöglich, die Bedingungen der equals-Methode aus der Klasse Object zu erfüllen, wenn man Instanzen von einer Super- und einer Subklasse miteinander vergleichen will. Weitere Details dazu kann man in der API-Dokumentation unter dem Stichwort Äquivalenzrelationen, konkret Symmetrie [4] nachlesen.

Sealed Classes funktionieren auch mit abstrakten Klassen und integrieren sich zudem gut mit den in der Vorgängerversion eingeführten Record-Datentypen. Es gibt aber ein paar Einschränkungen. Eine Sealed Class und alle erlaubten Subklassen müssen im selben Modul existieren. Im Fall von Unnamed Modules müssen sie sogar im gleichen Package liegen. Außerdem muss jede erlaubte Subklasse direkt von der Sealed Class ableiten. Die Subklassen dürfen übrigens wieder selbst entscheiden, ob sie weiterhin versiegelt, final oder komplett offen sein wollen. Die zentrale Versiegelung einer ganzen Klassenhierarchie von oben bis zur untersten Hierarchiestufe ist leider nicht möglich. Weitere Details finden sich auf der Projektseite des JEPs 360 [5].

Das zweite Mal dabei, sozusagen im Recall, ist das bereits in Java 14 als Preview eingeführte Pattern Matching for instanceof. Ein Pattern ist eine Kombination aus einem Prädikat, das auf eine Zielstruktur passt, und einer Menge von Variablen innerhalb dieses Musters. Diesen Variablen werden bei passenden Treffern die entsprechenden Inhalte zugewiesen und damit extrahiert. Die Intention des Pattern Matching ist letztlich die Destrukturier...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang