JDK 15: Die neuen Funktionen in Java 15

Java Development Kit 15, die Implementierung der nächsten Version von Java SE (Standard Edition) durch Oracle, wird heute, am 15. September 2020, als Produktionsversion verfügbar sein. Zu den Highlights von JDK 15 gehören Textblöcke, versteckte Klassen, eine Fremdspeicher-Zugriffs-API, der Z Garbage Collector und eine Vorschau versiegelter Klassen, Mustervergleiche und Datensätze.

JDK 15 ist nur eine kurzfristige Version, die nur sechs Monate lang vom Oracle Premier Support unterstützt wird, bis JDK 16 im nächsten März verfügbar ist. JDK 17, die nächste Version des Langzeit-Supports, die seit acht Jahren von Oracle unterstützt wird, wird voraussichtlich in einem Jahr verfügbar sein, gemäß der sechsmonatigen Release-Trittfrequenz von Oracle für Java SE-Versionen.

Entwickler können sich jetzt JDK 15 ansehen, um eine Vorstellung davon zu bekommen, was in JDK 17 enthalten sein wird, sagte Georges Saab, Präsident der Java Platform Group von Oracle. Die aktuelle LTS-Version ist JDK 11, die im September 2018 eingetroffen ist. LTS-Versionen erscheinen alle drei Jahre. JDK 15 folgt JDK 14, das am 17. März 2020 veröffentlicht wurde. 

Die neuen Funktionen und Änderungen in OpenJDK 15:

  • Ein zweiter Inkubator einer Fremdspeicher-Zugriffs-API, mit der Java-Programme sicher und effizient auf Fremdspeicher außerhalb des Java-Heaps zugreifen können. Die API sollte in der Lage sein, mit verschiedenen Arten von Fremdspeicher zu arbeiten, z. B. mit nativem, persistentem und verwaltetem Heap. Viele Java-Programme wie Ignite und MapDB greifen auf fremden Speicher zu. Die API würde dazu beitragen, die mit der Speicherbereinigung verbundenen Kosten und Unvorhersehbarkeit zu vermeiden, den Speicher prozessübergreifend zu teilen und den Speicherinhalt zu serialisieren und zu deserialisieren, indem Dateien dem Speicher zugeordnet werden. Die Java-API bietet derzeit keine zufriedenstellende Lösung für den Zugriff auf fremden Speicher. Mit dem neuen Vorschlag sollte es der API jedoch nicht möglich sein, die Sicherheit der JVM zu untergraben. Diese Fähigkeit durchläuft eine frühere Inkubatorphase in JDK 14, wobei in JDK 15 Verbesserungen angeboten werden. 
  • Eine Vorschau auf versiegelte Klassen. Versiegelte Klassen beschränken neben Schnittstellen, welche anderen Klassen oder Schnittstellen sie erweitern oder implementieren dürfen. Zu den Zielen dieser Funktion gehört es, dem Autor einer Klasse oder Schnittstelle zu ermöglichen, zu steuern, welcher Code für die Implementierung verantwortlich ist, eine deklarativere Möglichkeit als Zugriffsmodifikatoren bereitzustellen, um die Verwendung einer Oberklasse einzuschränken, und zukünftige Richtungen beim Mustervergleich zu unterstützen, indem die Vollständigkeit untermauert wird Analyse von Mustern.
  • Entfernen von Quellcode und Build-Unterstützung für Solaris / SPARC-, Solaris / x64- und Linux / SPARC-Ports, die in JDK 14 nicht mehr entfernt werden sollten, um sie in einer zukünftigen Version zu entfernen. Viele Projekte und Funktionen in der Entwicklung wie Valhalla, Loom und Panama erfordern erhebliche Änderungen an der CPU-Architektur und dem betriebssystemspezifischen Code. Durch die Einstellung der Unterstützung für Solaris- und SPARC-Ports können Mitarbeiter der OpenJDK-Community die Entwicklung neuer Funktionen beschleunigen, die die Plattform vorantreiben. Sowohl Solaris als auch SPARC wurden in den letzten Jahren von Linux-Betriebssystemen und Intel-Prozessoren abgelöst.
  • Datensätze, bei denen es sich um Klassen handelt, die als transparente Träger für unveränderliche Daten fungieren, werden nach dem Debüt als frühe Vorschau in JDK 14 in eine zweite Vorschauversion in JDK 15 aufgenommen. Zu den Zielen des Plans gehört die Entwicklung eines objektorientierten Konstrukts, das a ausdrückt Einfache Aggregation von Werten, die Programmierern hilft, sich auf die Modellierung unveränderlicher Daten anstatt auf erweiterbares Verhalten zu konzentrieren, automatisch datengesteuerte Methoden wie Equals und Assessors zu implementieren und langjährige Java-Prinzipien wie nominelle Typisierung und Migrationskompatibilität beizubehalten. Aufzeichnungen können als nominelle Tupel betrachtet werden. 
  • Kryptografische Signaturen basierend auf dem Edwards-Curve Digital Signature Algorithm (EdDSA). EdDSA ist ein modernes elliptisches Kurvenschema mit Vorteilen gegenüber vorhandenen Signaturschemata im JDK. EdDSA wird nur im SunEC-Anbieter implementiert. EdDSA ist aufgrund seiner im Vergleich zu anderen Signaturschemata verbesserten Sicherheit und Leistung gefragt. Es wird bereits in Kryptobibliotheken wie OpenSSL und BoringSSL unterstützt.
  • Neuimplementierung der älteren DatagramSocket-API durch Ersetzen der zugrunde liegenden Implementierungen der  APIs java.net.datagram.Socketund java.net.MulticastSocketdurch einfachere und modernere Implementierungen, die 1. einfach zu debuggen und zu warten sind und 2. mit virtuellen Threads arbeiten, die derzeit in Project Loom untersucht werden. Der neue Plan ist eine Fortsetzung des JDK-Verbesserungsvorschlags 353, mit dem die ältere Socket-API erneut implementiert wurde. Die aktuellen Implementierungen von java.net.datagram.Socketund java.net.MulticastSocketstammen aus JDK 1.0 und einer Zeit, als IPv6 noch in der Entwicklung war. Daher wird bei der aktuellen Implementierung von  MulticastSocket versucht, IPv4 und IPv6 auf schwer zu wartende Weise miteinander in Einklang zu bringen.
  • Deaktivieren Sie standardmäßig die voreingenommene Sperre und verwerfen Sie alle zugehörigen Befehlszeilenoptionen. Ziel ist es, die Notwendigkeit einer kontinuierlichen Unterstützung der kostspielig zu wartenden Legacy-Synchronisationsoptimierung für voreingenommene Sperren zu ermitteln, die in der virtuellen HotSpot-Maschine verwendet wird, um den Overhead für unkontrollierte Sperren zu verringern. Obwohl bei einigen Java-Anwendungen bei deaktivierter voreingenommener Sperrung möglicherweise eine Leistungsregression auftritt, sind die Leistungssteigerungen bei voreingenommener Sperrung im Allgemeinen weniger offensichtlich als früher.
  • Eine zweite Vorschau des Mustervergleichs instanceofnach einer vorherigen Vorschau in JDK 14. Mit dem Mustervergleich kann die allgemeine Logik in einem Programm, hauptsächlich das bedingte Extrahieren von Komponenten aus Objekten, einfacher und präziser ausgedrückt werden. Sprachen wie Haskell und C # haben sich aufgrund ihrer Kürze und Sicherheit für die Mustererkennung entschieden.
  • Versteckte Klassen, dh Klassen, die nicht direkt vom Bytecode anderer Klassen verwendet werden können, sind für Frameworks vorgesehen, die zur Laufzeit Klassen generieren und diese indirekt durch Reflektion verwenden. Eine versteckte Klasse kann als Mitglied eines Zugriffssteuerungsnests definiert und unabhängig von anderen Klassen entladen werden. Der Vorschlag würde die Effizienz aller Sprachen in der JVM verbessern, indem eine Standard-API die Definition versteckter Klassen ermöglicht, die nicht erkennbar sind und einen begrenzten Lebenszyklus haben. Frameworks innerhalb und außerhalb des JDK könnten dynamisch Klassen generieren, die stattdessen versteckte Klassen definieren könnten. Viele auf der JVM basierende Sprachen basieren auf dynamischer Klassengenerierung für Flexibilität und Effizienz. Zu den Zielen dieses Vorschlags gehören: Ermöglichen, dass Frameworks Klassen als nicht erkennbare Implementierungsdetails des Frameworks definieren;so können sie nicht von anderen Klassen verknüpft oder durch Reflexion entdeckt werden; Unterstützung für die Erweiterung eines Zugriffssteuerungsnestes um nicht erkennbare Klassen; und Unterstützung für das aggressive Entladen nicht auffindbarer Klassen, sodass Frameworks die Flexibilität haben, so viele wie nötig zu definieren. Ein weiteres Ziel ist es, die nicht standardmäßige API zu verwerfen. misc.Unsafe::defineAnonymousClassmit der Absicht, in einer zukünftigen Version nicht mehr entfernt zu werden. Außerdem darf die Java-Sprache aufgrund dieses Vorschlags nicht geändert werden.
  • Der Z Garbage Collector (ZGC) wechselt von einem experimentellen Merkmal zu einem Produkt im Rahmen dieses Vorschlags. ZGC ist in JDK 11 integriert, das im September 2018 eingeführt wurde, und ist ein skalierbarer Garbage Collector mit geringer Latenz. ZGC wurde als experimentelle Funktion eingeführt, da die Entwickler von Java entschieden haben, dass ein Feature dieser Größe und Komplexität sorgfältig und schrittweise eingeführt werden sollte. Seitdem wurde eine Reihe von Verbesserungen hinzugefügt, die vom gleichzeitigen Entladen von Klassen über das Aufheben des nicht verwendeten Speichers und die Unterstützung für die gemeinsame Nutzung von Klassendaten bis hin zu einer verbesserten NUMA-Erkennung und dem Vorberühren von Multithread-Heaps reichen. Außerdem wurde die maximale Heap-Größe von vier Terabyte auf 16 Terabyte erhöht. ZGC behebt Leistungsprobleme in Anwendungen, die große Datenmengen beinhalten, wie z. B. maschinelles Lernen.Hier möchten Benutzer sicher sein, dass die Datenverarbeitung nicht aufgrund der Speicherbereinigung unvorhersehbar ist oder lange Pausen einlegt. Zu den unterstützten Plattformen gehören Linux, Windows und MacOS.
  • Textblöcke, die sowohl in JDK 14 als auch in JDK 13 in der Vorschau angezeigt werden, sollen das Schreiben von Java-Programmen vereinfachen, indem sie das Ausdrücken von Zeichenfolgen über mehrere Zeilen Quellcode hinweg vereinfachen und in häufigen Fällen Escape-Sequenzen vermeiden. Ein Textblock ist ein mehrzeiliges Zeichenfolgenliteral, das die meisten Escape-Sequenzen überflüssig macht, die Zeichenfolge automatisch auf vorhersehbare Weise formatiert und dem Entwickler bei Bedarf die Kontrolle über das Format bietet. Ein Ziel des Textblockvorschlags ist die Verbesserung der Lesbarkeit von Zeichenfolgen in Java-Programmen, die Code bezeichnen, der in Nicht-Java-Sprachen geschrieben wurde. Ein weiteres Ziel besteht darin, die Migration von Zeichenfolgenliteralen zu unterstützen, indem festgelegt wird, dass jedes neue Konstrukt denselben Satz von Zeichenfolgen wie ein Zeichenfolgenliteral ausdrücken, dieselben Escape-Sequenzen interpretieren und auf dieselbe Weise wie ein Zeichenfolgenliteral bearbeitet werden kann.Die OpenJDK-Entwickler hoffen, Escape-Sequenzen hinzufügen zu können, um explizite Leerzeichen und Newline-Steuerung zu verwalten.
  • Der Müllsammler mit geringer Pause in Shenandoah würde zu einem Produktionsmerkmal und würde die experimentelle Phase verlassen. Es wurde vor einem Jahr in JDK 12 integriert.
  • Entfernung von Nashorn, das im März 2014 in JDK 8 debütierte, seitdem jedoch durch Technologien wie GraalVM überholt wurde. Der OpenJDK 15-Vorschlag fordert das Entfernen von Nashorn-APIs und des Befehlszeilentools jjs, mit dem Nashorn aufgerufen wird.
  • Verfall des RMI-Aktivierungsmechanismus zur zukünftigen Entfernung. Der RMI-Aktivierungsmechanismus ist ein veralteter Teil von RMI, der seit Java 8 optional ist. Die RMI-Aktivierung verursacht einen laufenden Wartungsaufwand. Kein anderer Teil von RMI wird veraltet sein.