Nach sechs Monaten Entwicklungszeit hat Oracle eine Plattform (Java Platform, Standard Edition 15) wird das Open-Source-Projekt OpenJDK als Referenzimplementierung verwendet. Java SE 15 behält die Abwärtskompatibilität mit früheren Versionen der Java-Plattform bei; alle zuvor geschriebenen Java-Projekte funktionieren ohne Änderungen, wenn sie unter der neuen Version ausgeführt werden. Installationsfertige Java SE 15-Builds (JDK, JRE und Server JRE) für Linux (x86_64), Windows und macOS. Vom OpenJDK-Projekt entwickelte Referenzimplementierung ist vollständig Open Source unter der GPLv2-Lizenz, mit Ausnahmen von GNU ClassPath, die eine dynamische Verknüpfung mit kommerziellen Produkten ermöglichen.
Java SE 15 wird als allgemeine Support-Version eingestuft und wird bis zur nächsten Version weiterhin Updates erhalten. Der Long Term Support (LTS)-Zweig soll Java SE 11 sein, das bis 2026 weiterhin Updates erhält. Der bisherige LTS-Zweig von Java 8 wird bis Dezember 2020 unterstützt. Die nächste LTS-Veröffentlichung ist für September 2021 geplant. Wir möchten Sie daran erinnern, dass das Projekt mit der Veröffentlichung von Java 10 auf einen neuen Entwicklungsprozess umgestellt hat, was einen kürzeren Zyklus für die Erstellung neuer Releases bedeutet. Neue Funktionen werden nun in einem ständig aktualisierten Hauptzweig entwickelt, der vorgefertigte Änderungen enthält und von dem alle sechs Monate Zweige abgezweigt werden, um neue Versionen zu stabilisieren.
Von :
- Unterstützung für den EdDSA-Algorithmus (Edwards-Curve Digital Signature Algorithm) zur Erstellung digitaler Signaturen ). Die vorgeschlagene EdDSA-Implementierung ist nicht von Hardwareplattformen abhängig, ist vor Seitenkanalangriffen geschützt (eine konstante Zeit aller Berechnungen ist gewährleistet) und weist bei gleichem Schutzniveau eine schnellere Leistung als die bestehende, in C-Sprache geschriebene ECDSA-Implementierung auf. Beispielsweise zeigt EdDSA, das eine elliptische Kurve mit einem 126-Bit-Schlüssel verwendet, eine ähnliche Leistung wie ECDSA mit einer elliptischen Kurve secp256r1 und einem 128-Bit-Schlüssel.
- experimentelle Unterstützung für versiegelte Klassen und Schnittstellen, die nicht von anderen Klassen und Schnittstellen zum Erben, Erweitern oder Überschreiben der Implementierung verwendet werden können. Versiegelte Klassen bieten auch eine deklarativere Möglichkeit, die Verwendung einer Oberklasse einzuschränken als Zugriffsmodifikatoren, basierend auf der expliziten Auflistung der zur Erweiterung zugelassenen Unterklassen.
Paket com.example.geometry;
öffentliche versiegelte Klassenform
erlaubt com.example.polar.Circle,
com.example.quad.Rectangle,
com.example.quad.simple.Square {…} - Unterstützung für versteckte Klassen, die nicht direkt vom Bytecode anderer Klassen verwendet werden können. Der Hauptzweck versteckter Klassen besteht darin, in Frameworks verwendet zu werden, die zur Laufzeit dynamisch Klassen generieren und diese indirekt verwenden . Solche Klassen haben normalerweise einen begrenzten Lebenszyklus, daher ist es nicht gerechtfertigt, sie für den Zugriff aus statisch generierten Klassen beizubehalten und führt nur zu einem erhöhten Speicherverbrauch. Durch versteckte Klassen entfällt außerdem die Notwendigkeit der nicht standardmäßigen API sun.misc.Unsafe::defineAnonymousClass, deren Entfernung in Zukunft geplant ist.
- Der Müllsammler ZGC (Z Garbage Collector) wurde stabilisiert und gilt als bereit für den breiten Einsatz. ZGC arbeitet im passiven Modus, minimiert die Latenz aufgrund der Speicherbereinigung so weit wie möglich (die Verzögerungszeit bei Verwendung von ZGC beträgt nicht mehr als 10 ms) und kann sowohl mit kleinen als auch mit großen Heaps arbeiten, deren Größe von mehreren hundert Megabyte bis zu vielen Terabyte reicht.
- Stabilisiert und für den allgemeinen Gebrauch bereit befunden
Müllsammler , arbeitet mit minimalen Pausen (Low-Pause-Time Garbage Collector). Shenandoah wurde von Red Hat entwickelt und zeichnet sich durch die Verwendung eines Algorithmus aus, der die Verzögerungszeit während der Garbage Collection reduziert, indem die Bereinigung parallel zur Ausführung von Java-Anwendungen ausgeführt wird. Die Größe der vom Garbage Collector verursachten Verzögerungen ist vorhersehbar und hängt nicht von der Größe des Heaps ab, d. h. für Heaps von 200 MB und 200 GB sind die Verzögerungen identisch ( über 50 ms und normalerweise innerhalb von 10 ms); - Die Unterstützung wurde stabilisiert und in die Sprache eingeführt – eine neue Form von String-Literalen, die es Ihnen ermöglicht, mehrzeilige Textdaten in den Quellcode einzubinden, ohne Zeichen-Escapezeichen zu verwenden und die ursprüngliche Textformatierung im Block beizubehalten. Der Block wird von drei doppelten Anführungszeichen eingerahmt.
Zum Beispiel anstelle von Code
String html=" » +
"\n\t" + " » +
"\n\t\t" + " „Java 1 ist da!“ » +
"\n\t" + " » +
„\n“ + „ ";Sie können Folgendes angeben:
String html = „““
»Java 1\
ist hier!
„““; - Legacy-DatagramSocket-API. 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 auch mit im Rahmen des Projekts entwickelten virtuellen Streams kompatibel ist . Im Falle einer möglichen Inkompatibilität mit vorhandenem Code wurde die alte Implementierung nicht entfernt und kann mit der Option jdk.net.usePlainDatagramSocketImpl aktiviert werden.
- Zweite experimentelle Implementierung vorgeschlagen im „instanceof“-Operator, der es Ihnen ermöglicht, sofort eine lokale Variable zu definieren, um auf den überprüften Wert zuzugreifen. Sie können beispielsweise sofort „if (obj Instanz von String s && s.length() > 5) {.. s.contains(..) ..}“ schreiben, ohne explizit „String s = (String) obj“ zu definieren.
Es war:
if (obj-Instanz der Gruppe) {
Gruppe group = (Group) obj;
var entries = group.getEntries();
}Nun kann auf die Definition „Group group = (Group) obj“ verzichtet werden:
if (obj Instanz der Gruppengruppe) {
var entries = group.getEntries();
} - zweite experimentelle Implementierung des Schlüsselworts „", das eine kompakte Form zum Definieren von Klassen bietet und es Ihnen ermöglicht, die explizite Definition verschiedener Low-Level-Methoden wie equal(), hashCode() und toString() in Fällen zu vermeiden, in denen Daten nur in Feldern gespeichert werden, deren Verhalten sich nicht ändert. Wenn eine Klasse Standardimplementierungen der Methoden equal(), hashCode() und toString() verwendet, kann sie auf deren explizite Definition verzichten:
öffentlicher Datensatz BankTransaction(LocalDate date,
doppelte Menge
String-Beschreibung) {}Diese Deklaration fügt zusätzlich zu den Konstruktor- und Getter-Methoden automatisch Implementierungen der Methoden equal(), hashCode() und toString() hinzu.
- eine zweite Vorschau der Foreign-Memory Access API, die es Java-Anwendungen ermöglicht, sicher und effizient auf Speicherbereiche außerhalb des Java-Heaps zuzugreifen, indem sie die neuen Abstraktionen MemorySegment, MemoryAddress und MemoryLayout manipulieren.
- und die Optimierungstechnik „Biased Locking“, die in der HotSpot-JVM verwendet wird, um den Sperraufwand zu reduzieren, wurde abgelehnt. Diese Technik hat auf Systemen mit atomaren Anweisungen, die von modernen CPUs bereitgestellt werden, ihre Relevanz verloren und ist aufgrund ihrer Komplexität zu arbeitsintensiv für die Wartung.
- veralteter Mechanismus , die in einer zukünftigen Version entfernt wird. Es wird darauf hingewiesen, dass die RMI-Aktivierung veraltet ist, in Java 8 in die Kategorie einer Option verbannt wird und in der modernen Praxis fast nie verwendet wird.
- JavaScript-Engine , das in Java SE 11 veraltet war.
- Ports für Solaris OS und SPARC-Prozessoren (Solaris/SPARC, Solaris/x64 und Linux/SPARC). Durch das Entfernen dieser Ports kann die Community die Entwicklung neuer OpenJDK-Funktionen beschleunigen, ohne Zeit mit der Wartung von Solaris- und SPARC-spezifischen Funktionen zu verschwenden.
Source: opennet.ru