🥇Release Java SE 15

Nach sechs Monaten Entwicklung hat die Firma Oracle die die Plattform Java SE 15 (Java Platform, Standard Edition 15), dessen Referenzimplementierung auf dem OpenJDK-Projekt basiert. Java SE 15 gewährleistet die Abwärtskompatibilität mit früheren Java-Versionen, sodass alle zuvor geschriebenen Java-Projekte ohne Änderungen weiterhin mit der neuen Version ausgeführt werden können. Bereit zum Installieren sind die Build-Versionen von Java SE 15 (JDK, JRE und Server JRE) werden für Linux (x86_64), Windows und macOS. Die Referenzimplementierung wurde im Rahmen des OpenJDK-Projekts entwickelt Java 15 ist vollständig unter der GPLv2-Lizenz mit Ausnahmen von GNU ClassPath geöffnet, die eine dynamische Verknüpfung mit kommerziellen Produkten ermöglichen.

Java SE 15 gehört zur Kategorie der Versionen mit normalem Support, Updates hierfür werden bis zur nächsten Version bereitgestellt. Für eine Version mit langfristigem Support (LTS) sollte Java SE 11 verwendet werden, Updates hierfür werden bis 2026 bereitgestellt. Die vorherige LTS-Version, Java 8, wird bis Dezember 2020 unterstützt. Der nächste LTS-Release ist für September 2021 geplant. Beachten Sie, dass mit der Veröffentlichung von Java 10 das Projekt auf einen neuen Entwicklungsprozess umgestellt hat, der einen kürzeren Zyklus für die Erstellung neuer Releases vorsieht. Die neue Funktionalität wird jetzt in einem konstant aktualisierten Hauptzweig entwickelt, in den bereits fertige Änderungen integriert werden und von dem alle sechs Monate Stabilitätszweige für neue Releases abgezweigt werden.

Von Neuheiten Java 15 kann markieren:

Eingebaut Unterstützung des Algorithmus zur Erstellung digitaler Signaturen EdDSA (Edwards-Curve Digital Signature Algorithm) RFC 8032). Die vorgeschlagene EdDSA-Implementierung ist plattformunabhängig, gegen Angriffe über seitliche Kanäle geschützt (alle Berechnungen erfolgen in konstanter Zeit) und bietet eine bessere Leistung als die vorhandene ECDSA-Implementierung in C, bei gleichem Schutzniveau. Zum Beispiel zeigt EdDSA mit einer elliptischen Kurve und einem 126-Bit-Schlüssel eine Leistung ähnlich der von ECDSA mit der elliptischen Kurve secp256r1 und einem 128-Bit-Schlüssel.
Hinzugefügt experimentelle Unterstützung für versiegelte („sealed“) Klassen und Schnittstellen, die von anderen Klassen und Schnittstellen nicht zur Vererbung, Erweiterung oder Überschreibung der Implementierung verwendet werden können. Versiegelte Klassen bieten auch einen deklarativeren Ansatz zur Einschränkung der Nutzung der Superklasse als Zugangssmodifizierer, indem sie explizit die zulässigen Unterklassen auflisten.
package com.example.geometry;
public sealed class Shape
permits com.example.polar.Circle,
com.example.quad.Rectangle,
com.example.quad.simple.Square {…}
Hinzugefügt Unterstützung für verborgene Klassen, die nicht direkt von Bytecode anderer Klassen verwendet werden können. Der Hauptzweck verborgener Klassen besteht darin, in Frameworks eingesetzt zu werden, die Klassen zur Laufzeit dynamisch generieren und diese indirekt verwenden, durch Reflexion. Diese Klassen haben normalerweise einen begrenzten Lebenszyklus, daher ist ihre Unterstützung für den Zugriff aus statisch generierten Klassen nicht gerechtfertigt und führt nur zu einem erhöhten Speicherverbrauch. Verborgene Klassen ermöglichen es auch, ohne die nicht standardmäßige API sun.misc.Unsafe::defineAnonymousClass auszukommen, die in Zukunft entfernt werden soll.
Der Z Garbage Collector (ZGC) wurde stabilisiert und als bereit für den allgemeinen Einsatz anerkannt. ZGC arbeitet im passiven Modus und minimiert, wo immer möglich, Verzögerungen durch die Müllabfuhr (die Stop-Zeit bei Verwendung von ZGC überschreitet 10 ms nicht) und kann sowohl mit kleinen als auch mit riesigen Heaps arbeiten, die von mehreren hundert Megabyte bis zu vielen Terabyte reichen.
Wurde stabilisiert und als bereit für den allgemeinen Einsatz anerkannt
Müllsammler Shenandoah, der mit minimalen Unterbrechungen arbeitet (Low-Pause-Time Garbage Collector). Shenandoah wurde von Red Hat entwickelt und zeichnet sich durch einen Algorithmus aus, der die Stop-Zeiten während der Speicherbereinigung reduziert, indem die Reinigung parallel zur Ausführung von Java-Anwendungen durchgeführt wird. Die vom Garbage Collector verursachten Verzögerungen sind vorhersehbar und unabhängig von der Größe des Heaps, d.h. bei Heaps von 200 MB und 200 GB sind die Verzögerungen identisch (nicht überschreiten 50 ms und liegen normalerweise bei 10 ms);
Die Unterstützung für Textblöcke — eine neue Form von Zeichenliteralen, die es ermöglicht, mehrzeilige Textdaten ohne Zeichenescapierung in den Quellcode einzufügen und die ursprüngliche Formatierung des Textes im Block beizubehalten. Der Block wird durch drei doppelte Anführungszeichen eingerahmt.
Zum Beispiel anstelle des Codes
String html = "" +
"\n\t" + "" +
"\n\t\t" + "
\"Java 15 ist da!\"" +
"\n\t" + "" +
"\n" + "";
kann man angeben:
String html = """
<HTML>
<BODY>
"Java 15\
ist da!"
</BODY>
""";
Überarbeitet API Legacy DatagramSocket. Die alten Implementierungen von java.net.DatagramSocket und java.net.MulticastSocket wurden durch eine moderne Implementierung ersetzt, die einfacher zu debuggen und zu warten ist und mit den virtuellen Threads kompatibel ist, die im Rahmen des Projekts entwickelt werden. Loom. Um mögliche Komplikationen mit bestehendem Code zu vermeiden, wurde die alte Implementierung nicht entfernt und kann über die Option jdk.net.usePlainDatagramSocketImpl aktiviert werden.
Eine zweite experimentelle Implementierung wurde vorgeschlagen Musterabgleich im Operator „instanceof“, die es ermöglicht, die lokale Variable direkt für den Zugriff auf den überprüften Wert zu definieren. Zum Beispiel kann man direkt schreiben „if (obj instanceof String s && s.length() > 5) {.. s.contains(..) ..}“ ohne die explizite Definition „String s = (String) obj“.
War:
if (obj instanceof Group) {
Group group = (Group) obj;
var entries = group.getEntries();
}
Jetzt kann auf die Definition „Group group = (Group) obj“ verzichtet werden:
if (obj instanceof Group group) {
var entries = group.getEntries();
}
Es wurde vorgeschlagen, die zweite experimentelle Implementierung des Schlüsselworts „record«, das eine kompakte Form zur Definition von Klassen bereitstellt und es ermöglicht, ohne explizite Definition verschiedener low-level Methoden wie equals(), hashCode() und toString() auszukommen, wenn Daten nur in Feldern gespeichert werden, deren Bearbeitungsverhalten unverändert bleibt. Wenn im Klassendesign generische Implementierungen der Methoden equals(), hashCode() und toString() verwendet werden, kann auf deren explizite Definition verzichtet werden:
public record BankTransaction(LocalDate date,
double amount,
String description) {}
Diese Deklaration führt automatisch zu der Hinzufügung von Implementierungen der Methoden equals(), hashCode() und toString() zusätzlich zum Konstruktor und den Methoden, die die Datenänderungen überwachen (Getter).
Vorgeschlagen eine zweite, vorläufige Variante der Foreign-Memory Access API, die es Java-Anwendungen ermöglicht, sicher und effizient auf Speicherbereiche außerhalb des Java-Heaps zuzugreifen, indem sie mit neuen Abstraktionen wie MemorySegment, MemoryAddress und MemoryLayout arbeiten.
Die Unterstützung und die veraltete Optimierungstechnik Biased Locking, die in der HotSpot JVM verwendet wurde, um die Overhead-Kosten durch Sperren zu reduzieren, wurde als obsolet erklärt. Diese Technik hat an Relevanz verloren in Systemen mit atomaren Befehlen, die von modernen CPUs bereitgestellt werden, und ist aufgrund ihrer Komplexität zu wartungsintensiv.
Wurde bekanntgegeben veralteter Mechanismus RMI-Aktivierung, der in einer der nächsten Versionen entfernt wird. Es wird festgestellt, dass die RMI-Aktivierung veraltet ist, seit Java 8 als Option eingestuft wurde und in der modernen Praxis kaum Verwendung findet.
Entfernt JavaScript-Engine Nashorn, das in Java SE 11 als veraltet deklariert wurde.
Entfernt Ports für das Betriebssystem Solaris und SPARC-Prozessoren (Solaris/SPARC, Solaris/x64 und Linux/SPARC). Die Entfernung dieser Ports ermöglicht es der Gemeinschaft, die Entwicklung neuer Funktionen für OpenJDK zu beschleunigen, ohne Zeit mit der Pflege von Solaris- und SPARC-spezifischen Besonderheiten zu verschwenden.