Nach sechsmonatiger Entwicklung hat die Firma Oracle plattforms (Java Platform, Standard Edition 15), dessen Referenzimplementierung das OpenJDK-Projekt nutzt. Java SE 15 gewährleistet die Abwärtskompatibilität mit früheren Versionen der Java-Plattform; alle zuvor geschriebenen Java-Projekte funktionieren ohne Änderungen unter der neuen Version. Installationsfertige Builds von Java SE 15 (JDK, JRE und Server JRE) für Linux (x86_64), Windows und macOS. Die Referenzimplementierung wurde im Rahmen des OpenJDK-Projekts entwickelt ist vollständig unter der GPLv2-Lizenz mit Ausnahmen von GNU ClassPath geöffnet, die dynamische Bindungen an kommerzielle Produkte erlauben.
Java SE 15 gehört zur Kategorie der Versionen mit gewöhnlichem Supportzeitraum, für die Updates bis zur nächsten Veröffentlichung bereitgestellt werden. Für Versionen mit langfristigem Support (LTS) sollte Java SE 11 verwendet werden, für die Updates bis 2026 bereitgestellt werden. Die vorherige LTS-Version, Java 8, wird bis Dezember 2020 unterstützt. Die nächste LTS-Version wird für September 2021 erwartet. Zur Erinnerung: Ab der Veröffentlichung von Java 10 ist das Projekt auf einen neuen Entwicklungsprozess umgestiegen, der einen kürzeren Zyklus für die Erstellung neuer Versionen vorsieht. Neue Funktionen werden nun in einem durchgehend aktualisierten Master-Zweig entwickelt, der bereits fertige Änderungen enthält und von dem alle sechs Monate Zweige zur Stabilisierung neuer Versionen abgezweigt werden.
Aus :
- Unterstützung des EdDSA-Signaturalgorithmus (Edwards-Curve Digital Signature Algorithm) ). Die vorgeschlagene EdDSA-Implementierung ist plattformunabhängig, resistent gegen Angriffe über Seitenkanäle (alle Berechnungen erfolgen in konstanter Zeit) und übertrifft hinsichtlich der Leistung die bestehende ECDSA-Implementierung, die in C geschrieben ist, bei gleichem Schutzniveau. Zum Beispiel zeigt EdDSA unter Verwendung einer elliptischen Kurve mit einem 126-Bit-Schlüssel eine Leistung, die der von ECDSA mit der elliptischen Kurve secp256r1 und einem 128-Bit-Schlüssel entspricht.
- Experimentelle Unterstützung für versiegelte („sealed“) Klassen und Schnittstellen, die von anderen Klassen und Schnittstellen nicht zur Vererbung, Erweiterung oder Überlagerung der Implementierung verwendet werden können. Versiegelte Klassen bieten außerdem eine deklarativere Möglichkeit, die Verwendung einer Superklasse zu beschränken als Zugriffsmodifikatoren, indem sie explizit eine Liste von Unterklassen angeben, die zur Erweiterung zugelassen sind.
package com.example.geometry;
public sealed class Shape
permits com.example.polar.Circle,
com.example.quad.Rectangle,
com.example.quad.simple.Square {…} - Unterstützung für versteckte Klassen, die nicht direkt von den Bytecodes anderer Klassen verwendet werden können. Der Hauptzweck versteckter Klassen besteht darin, in Frameworks verwendet zu werden, die während der Laufzeit Klassen dynamisch generieren und diese indirekt über . Solche Klassen haben normalerweise eine begrenzte Lebensdauer, weshalb ihre Unterstützung für den Zugriff aus statisch generierten Klassen nicht gerechtfertigt ist und nur zu einem erhöhten Speicherverbrauch führt. Versteckte Klassen ermöglichen auch den Verzicht auf die nicht standardmäßige API sun.misc.Unsafe::defineAnonymousClass, die in Zukunft entfernt werden soll.
- Der Garbage Collector ZGC (Z Garbage Collector) wurde stabilisiert und als bereit für den breiten Einsatz anerkannt. ZGC arbeitet im passiven Modus, minimiert so weit wie möglich Verzögerungen durch Garbage Collection (die Stop-Zeit bei Verwendung von ZGC überschreitet 10 ms nicht) und kann sowohl mit kleinen als auch mit riesigen Haufen von mehreren hundert Megabyte bis hin zu vielen Terabyte arbeiten.
- Wurde stabilisiert und als bereit für den breiten Einsatz anerkannt
Garbage Collector , der mit minimalen Unterbrechungen (Low-Pause-Time Garbage Collector) arbeitet. Shenandoah wurde von Red Hat entwickelt und zeichnet sich durch die Verwendung eines Algorithmus aus, der die Stop-Zeiten während der Garbage Collection verringert, indem die Bereinigung parallel zur Ausführung von Java-Anwendungen erfolgt. Die vom Garbage Collector verursachten Verzögerungen sind vorhersehbar und hängen nicht von der Haufengröße ab, d.h. für Haufen von 200 MB und 200 GB sind die Verzögerungen identisch ( nicht 50 ms und liegen normalerweise bei 10 ms); - Die Unterstützung für wurde stabilisiert und in die Sprache eingeführt — eine neue Form von Zeichenliteralen, die es ermöglicht, mehrzeilige Textdaten in den Quellcode einzufügen, ohne Zeichen maskieren zu müssen, und die ursprüngliche Formatierung des Textes im Block beizubehalten. Der Block wird durch drei doppelte Anführungszeichen umschlossen.
Zum Beispiel kann anstelle von
String html = "<HTML>" +
"\n\t" + "<BODY>" +
"\n\t\t" + "<H1>\"Java 15 ist da!\"</H1>" +
"\n\t" + "</BODY>" +
"\n" + "</HTML>";es kann angegeben werden:
String html = """
<HTML>
<BODY>
<H1>"Java 15\
ist da!"</H1>
</BODY>
</HTML>"""; - API Legacy DatagramSocket. Alte Implementierungen von java.net.DatagramSocket und java.net.MulticastSocket wurden durch eine moderne Implementierung ersetzt, die einfacher zu debuggen und zu warten ist und die mit den virtuellen Threads kompatibel ist, die im Rahmen des Projekts entwickelt werden. . Um mögliche Kompatibilitätsprobleme mit bestehendem Code zu vermeiden, wurde die alte Implementierung nicht entfernt und kann mit der Option jdk.net.usePlainDatagramSocketImpl aktiviert werden.
- Eine zweite experimentelle Implementierung wurde vorgeschlagen im Operator „instanceof“, der es ermöglicht, sofort eine lokale Variable zum Zugriff auf den geprüften Wert zu definieren. Zum Beispiel kann man sofort schreiben „if (obj instanceof String s && s.length() > 5) {.. s.contains(..) ..}“ ohne die explizite Definition „String s = (String) obj“.
Früher:
if (obj instanceof Group) {
Group group = (Group) obj;
var entries = group.getEntries();
}Jetzt kann man auf die Definition „Group group = (Group) obj“ verzichten:
if (obj instanceof Group group) {
var entries = group.getEntries();
} - die zweite experimentelle Implementierung des Schlüsselworts „“, das eine kompakte Form zur Definition von Klassen bereitstellt, die es ermöglicht, ohne explizite Definition verschiedener Low-Level-Methoden wie equals(), hashCode() und toString() auszukommen, wenn die Daten nur in Feldern gespeichert werden und das Verhalten im Umgang mit ihnen unverändert bleibt. Wenn in der Klasse typisierte 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 Ankündigung führt automatisch zur Implementierung der Methoden equals(), hashCode() und toString() zusätzlich zum Konstruktor und den Methoden, die die Datenänderung steuern (Getter).
- der zweite Vorab-Entwurf der API für den Zugriff auf fremden Speicher, der es Java-Anwendungen ermöglicht, sicher und effizient auf Speicherseiten außerhalb des Java-Haufs zuzugreifen, indem neue Abstraktionen wie MemorySegment, MemoryAddress und MemoryLayout verwendet werden.
- und die Technik der Biased Locking, die in der HotSpot JVM zur Reduzierung der Kosten durch Sperren verwendet wurde, wurde als veraltet erklärt. Diese Technik ist auf Systemen mit atomaren Anweisungen, die von modernen CPUs bereitgestellt werden, nicht mehr relevant und ist aufgrund ihrer Komplexität zu wartungsintensiv.
- RMI Activation wurde , der in einer der nächsten Versionen entfernt wird. Es wird darauf hingewiesen, dass RMI Activation seit Java 8 als veraltet gilt und kaum noch in der modernen Praxis verwendet wird.
- Die JavaScript-Engine , die in Java SE 11 als veraltet erklärt wurde.
- Ports für das Betriebssystem Solaris und SPARC-Prozessoren (Solaris/SPARC, Solaris/x64 und Linux/SPARC). Das Entfernen der angegebenen Ports wird der Community ermöglichen, die Entwicklung neuer Funktionen für OpenJDK zu beschleunigen, ohne Zeit mit der Pflege von spezifischen Besonderheiten für Solaris und SPARC zu verschwenden.
Quelle: opennet.ru
