Java 15 versteckt und versiegelt Klassen

Mit Java 15 ist das erste Release nach dem 25. Geburtstag der Programmiersprache erschienen. Insgesamt zehn Neuerungen fließen über JDK Enhancement Proposals (JEPs) in die neue Version ein, von denen einige noch als Preview gekennzeichnet sind. Vier APIs beziehungsweise Features gelten derweil als überholt (deprecated).

Als reguläres Release wird Oracle vollen Support für das JDK 15 nur bis zum Release von Java 16 anbieten, das für März 2021 geplant ist. Anschließend soll im September 2021 das JDK 17 als nächstes LTS-Release (Long-term Support) folgen, das wie die aktuelle LTS-Variante JDK 11 acht Jahre offizielle Unterstützung erhält.

Eingeschränkter Klassenzugriff

Java 15 führt gleich zwei neue Formen von Klassen ein, die Einschränkungen über die gewohnten Zugriffsparameter public, protected und private hinaus bieten. Sealed Classes (JEP 360) sind derzeit noch als Preview gekennzeichnet und betreffen neben Klassen auch Interfaces. Darüber können Entwickler festlegen, welche anderen Klassen oder Interfaces die Sealed-Varianten implementieren beziehungsweise erweitern dürfen.

Lesen Sie auch

25 Jahre: Silberner Glückwunsch, Java!

Die Hidden Classes (JEP 371) zielen vor allem auf diejenigen, die Frameworks erstellen. Reguläre Klassen dürfen die versteckten nicht direkt verwenden, sondern Frameworks können sie als nicht auffindbare Implementierung zur Laufzeit erstellen und nur indirekt über Reflexion nutzen.

Fertiggestellte Aufräumarbeiten

Mit dem ZGC und dem Shenandoah wandern gleich zwei Garbage Collectors (GCs) vom experimentellen in den produktiven Status. Das JEP 377 betrifft den Z Garbage Collector, der intern bei Oracle entstanden ist. Nach der Offenlegung hielt er unter dem JEP 333 zunächst als experimentell gekennzeichnet Einzug in Java 11. Der ZGC ist ein nebenläufiger, regionsbasierter Garbage Collector, der inkrementell aufräumt. Er ist vor allem auf geringe Pause-Zeiten ausgelegt, die nicht über 10 Millisekunden betragen sollen, und kann Heaps von relativ kleinem (Hunderte Megabyte) bis zu sehr großen Umfang im Terabytebereich gleichermaßen verwalten.

Der Shenandoah GC trat unter dem JEP 189 erstmals in Java 12 auf und war bisher als experimentell gekennzeichnet. Mit dem JEP 379 gilt er wie der ZGC in Java 15 als bereit für den produktiven Einsatz. Auch er soll geringe Pause-Zeiten bringen. Wie bereits im ursprünglichen Proposal betont das aktuelle JEP, dass der Garbage Collector nicht G1 als Standard-Garbage-Collector von Java ablösen soll.

Signaturen und Sockets

Das JEP 339 führt kryptografische Signaturen nach dem Edwards-Curve Digital Signature Algorithm (EdDSA) ein, einem Signaturverfahren auf Basis elliptischer Kurven. Die Java-Implementierung zielt vor allem auf eine plattformunabhängige Umsetzung mit einer besseren Performance als die derzeitige ECDSA-Umsetzung mit C-Code, die es jedoch nicht ersetzen soll.

Unter dem JEP 373 erfolgt eine neue Implementierung der DatagramSocket-API, konkret von java.net.DatagramSocket und java.net.MulticastSocket, durch einfachere und zeitgemäßere Umsetzungen. Die bisherigen Implementierungen gehen auf das JDK 1.0 zurück und vermischen laut dem Proposal Java- und C-Code.

Zweite Preview-Runde

Gleich drei JEPs bringen in JDK 14 eingeführte, experimentelle Funktionen in die zweite Runde: Records, Pattern Matching für instanceof und die Foreign-Memory Access API. Alle drei gelten derweil weiterhin als Preview.

Letztere API, die das JEP 383 beschreibt, dient zum sicheren und effizienten Zugriff auf Speicher außerhalb des Java-Heap. Im Vergleich zur Umsetzung in Java 14 sind einige Ergänzungen hinzugekommen, darunter eine VarHandle-API zum Verwalten von Handles und ein Spliterator-Interface für den parallelen Zugriff auf ein Speichersegment.

Das JEP 375 betrifft das Pattern Matching für den instanceof-Operator. Es soll Boilerplate-Code reduzieren, indem es das Überprüfen der Zugehörigkeit zu einem bestimmten Typ über instanceof mit einem Test-Pattern kombiniert.

Unveränderliche Daten im Zugriff

Die Records (JEP 384) dienen als objektorientiertes Konstrukt zum Speichern simpler Werte in Form von Immutable Data, also unveränderlichen Daten. Java kümmert sich dabei um die Implementierung von Methoden zum Vergleichen und Zugriff auf die Inhalte und kompiliert folgendes Konstrukt

record Point(int x, int y) { }

mit einer impliziten Implementierung der Variablen als final und einem passenden Konstruktor. Letzterer lässt sich wahlweise auch explizit deklarieren. Die Umsetzung sieht laut dem JEP 384 folgendermaßen aus:

record Point(int x, int y) { 
    // Implicitly declared fields
    private final int x;
    private final int y;

    // Other implicit declarations elided ...

    // Implicitly declared canonical constructor
    Point(int x, int y) {
        this.x = x;
        this.y = y;
    }
}

Zeilenweise Text

Der letzte Neuzugang betrifft unter dem JEP 378 Text Blocks: mehrzeilige String-Literale, die ohne Escape-Sequenzen auskommen und die Strings in einer vorhersehbaren Weise formatieren. Die Textblöcke sind als JEP 355 in Java 13 eingeflossen und galten bisher als experimentell. Bereits damals ersetzten sie die Raw String Literals, womit der zugehörige JEP 326 als zurückgezogen (withdrawn) gilt.

Die Textblöcke sollen vor allem das Einbetten von HTML-, XML-, SQL-, JSON- oder auch Programmcode vereinfachen, wie das Beispiel einer SQL-Abfrage aus dem JEP zeigt:

String query = """
               SELECT "EMP_ID", "LAST_NAME" FROM "EMPLOYEE_TB"
               WHERE "CITY" = 'INDIANAPOLIS'
               ORDER BY "EMP_ID", "LAST_NAME";
               """;

Und tschüss!

Vier JEPs führen keine neuen Features ein, sondern entfernen vorhandene. Nennenswert ist vor allem der unter dem JEP 372 durchgeführte endgültige Abschied der Nashorn JavaScript Engine, die bereits seit Java 11 als überholt gilt. Sie war ursprünglich unter JEP 174 in Java 8 eingeflossen. Als Grund für den Abschied nennen die Entwickler die schnelle Entwicklung von ECMAScript, wodurch die Pflege der Nashorn-Engine zu schwierig geworden sei.

Außerdem gelten in Java 15 die Legacy-Synchronisierung über Biased Locking (JEP 374) und die RMI Activation (JEP 385) als überholt. Letzteres Proposal betrifft explizit nicht das grundsätzliche Konzept der Remote Method Invocation (RMI), sondern lediglich die Aktivierung, die seit Java 8 als optional gilt.

Die Solaris- und SPARC-Ports von Java entfallen ebenfalls endgültig als JEP 381, nachdem sie bereits im vorherigen Release als "deprecated" gekennzeichnet waren.

Weitere Details lassen sich der OpenJDK-Site zu Java 15 und dem Oracle-Blog entnehmen. Letzterer enthält Links zu den kommerziellen Angeboten, und die Open-Source-Implementierung findet sich auf der JDK-Site.

(rme)