Was ist neu in Java 15?

Versteckt Klassen, Sealed Klassen, Textblöcke , Records und EdDSA: JDK 15 hat viel Wert.



Wie einer meiner Lieblingsausdrücke sagt, gibt es in Java 15 eine Menge reichhaltiger Schokoladengüte. Die neue Version (veröffentlicht am 15. September 2020) enthält 14 wichtige Änderungen (JEPs) zur Verbesserung des JDK. Dieser Artikel bietet einen schnellen Überblick über neue Produkte basierend auf den im JEP enthaltenen Informationen.



Die 14 JEP können in fünf Gruppen unterteilt werden. Eine detailliertere Studie finden Sie in der Dokumentation zu den einzelnen Studien.



Neue Funktionen, die Ihnen den Atem rauben:

• JEP 339: Edwards Curve Digital Signature Algorithmus (EdDSA)
• JEP 371: Versteckte Klassen

Ergänzungen zu bestehenden Java SE-Standardfunktionen:

• JEP 378: Textblöcke
• JEP 377: ZGC Garbage Collector
• JEP 379: Shenandoah - Müllsammler mit niedriger Pause

Verbesserungen der alten Java SE-Funktionalität:

• JEP 373: Überarbeitung der veralteten DatagramSocket-API

Wir freuen uns auf neue Produkte:

• JEP 360: Versiegelte Klassen (Vorschau)
• JEP 375: Pattern Matching zum Beispiel (Zweite Vorschau)
• JEP 384: Einträge (Zweiter Entwurf)
• JEP 383: Externer Speicherzugriffs-API (zweite Inkubatorfunktion)

Entfernung und Beendigung des Supports:

• JEP 372: Nashorn JavaScript Engine
• JEP 374:
• JEP 381: Solaris SPARC
• JEP 385: RMI

,

Edwards Curve Digital Signature-Algorithmus ( JEP 339 ). Ich werde als erster zugeben, dass der Edwards-Curve-Algorithmus für digitale Signaturen (EdDSA) etwas über meine Kenntnisse der Verschlüsselung hinausgeht. Okay, ich weiß überhaupt nichts darüber. Dieses JEP ist jedoch als plattformunabhängige Implementierung von EdDSA mit besserer Leistung als die vorhandene C-Implementierung ECDSA konzipiert.



Gemäß der JDK-Dokumentation ist EdDSA ein modernes Signaturschema für elliptische Kurven, das gegenüber den im JDK vorhandenen mehrere Vorteile bietet.



Implementierungsziele:

1. Der Hauptzweck dieses JEP ist die Implementierung des in RFC 8032 standardisierten Signaturschemas . Das neue System ersetzt jedoch nicht ECDSA.
2. - EdDSA , ECDSA . , EdDSA, Curve25519 ~126 , , ECDSA, secp256r1 ~128 .
3. , . .

Jetzt weißt du mehr als ich. Seien Sie gespannt auf einen Artikel im Java Magazine, in dem EdDSA bald erklärt wird.



Versteckte Klassen ( JEP 371 ) sind Klassen, die nicht direkt vom Bytecode anderer Klassen aufgerufen werden können. Sie sollen von Frameworks verwendet werden, die zur Laufzeit dynamisch Klassen erstellen und diese indirekt über einen Reflexionsmechanismus verwenden. Dynamisch generierte Klassen sind möglicherweise nur für eine begrenzte Zeit erforderlich. Wenn Sie sie also für die Lebensdauer einer statisch generierten Klasse behalten, kann sich der Speicherbedarf unnötig erhöhen.



Dynamisch generierte Klassen sind ebenfalls nicht nachweisbar. Das Finden solcher Klassen mit Namen wäre nachteilig, da dies ihren Zweck untergräbt, nämlich dass sie nur ein Implementierungsdetail einer statisch generierten Klasse sind.



Die Veröffentlichung der versteckten Klassen bildet die Grundlage für Entwickler, die nicht standardmäßige API sun.misc.Unsafe :: defineAnonymousClass nicht mehr zu verwenden . Oracle beabsichtigt, diese Klasse in Zukunft zu entfernen und zu entfernen.

Ergänzungen zu bestehenden Java SE-Standards

Die Textblöcke ( JEP 378 ), die aus Project Amber stammten, wurden schließlich nach zwei vorläufigen Versionen in JDK 13 und 14 veröffentlicht. Der Zweck ihrer Erstellung war der Wunsch der Entwickler, die Schwierigkeit zu verringern, mehrzeilige String-Literale in Java zu deklarieren und zu verwenden.



Textblöcke formatieren Zeichenfolgen automatisch auf vorhersehbare Weise. Wenn dies jedoch nicht ausreicht, kann der Entwickler die Formatierung übernehmen. Die zweite Version der vorläufigen Funktionalität führt zwei neue Escape-Sequenzen für den Umgang mit Zeilenumbrüchen und Leerzeichen ein. Beispielsweise unterdrückt \ <Zeilenterminator> das Einfügen eines Zeilenumbruchzeichens explizit.



Um eine lange Textzeile zu drucken, mussten Sie zuvor wie folgt schreiben:





Die Verwendung von \ erleichtert das Lesen des Codes:





Die Escape-Sequenz von \ kann verhindern, dass nachgestellte Leerzeichen entfernt werden. Daher stellt der folgende Text drei Zeilen dar, von denen jede aus genau fünf Zeichen besteht (in der mittleren Zeile, die Grün entspricht, wird \ s nicht verwendet, da sie bereits fünf Zeichen enthält).





Der ZGC-Garbage Collector ( JEP 377 ) wurde als experimentelles Feature in JDK 11 eingeführt. Jetzt hat es offiziellen Status erhalten. ZGC ist ein paralleler, NUMA-fähiger, skalierbarer Garbage Collector mit geringer Garbage Collection-Latenz (weniger als 10 Millisekunden, selbst bei Multi-Terabyte-Heaps). Die von Oracle getestete durchschnittliche Pausenzeit beträgt weniger als 1 Millisekunde und das Maximum weniger als 2 Millisekunden. In Abbildung 1 werden der Java Parallel Garbage Collector G1 und ZGC verglichen, wobei die ZGC-Pausenzeit um den Faktor 10 erhöht wurde.





Abbildung 1. Vergleich der Pausenzeiten des Garbage Collectors



Bei vielen Workloads ist G1 (das immer noch die Standardeinstellung ist) möglicherweise etwas schneller als ZGC. Auch für sehr kleine Haufen, wie zum Beispiel solche, die nur wenige hundert Megabyte groß sind, kann der G1 schneller sein. Es wird daher empfohlen, eigene Tests mit Ihren Lasten durchzuführen, um festzustellen, welcher Garbage Collector verwendet werden soll.



Wichtig: Da der ZGC nicht mehr experimentell ist (im Oracle OpenJDK-Build und im Oracle JDK enthalten), müssen Sie -XX: + UnlockExperimentalVMOptions nicht mehr verwenden , um ihn zu aktivieren.



Shenandoah ( JEP 379) Ist eine andere Variante des Garbage Collector in einigen OpenJDK-Builds verfügbar? Es ist seit JDK 12 experimentell. Wie bei ZGC ist XX: + UnlockExperimentalVMOptions nicht mehr erforderlich.

Modernisierung der alten Java SE-Funktionalität

Überarbeitung der veralteten DatagramSocket-API ( JEP 373 ). Betrachten Sie dies im Grunde als ein Refactoring von Jurassic-Code, da dieser JEP die alten, schwer zu wartenden Implementierungen der APIs java.net.DatagramSocket und java.net.MulticastSocket durch einfachere, moderne Implementierungen ersetzt, die einfach zu warten und zu debuggen sind und dies auch tun werden Arbeiten Sie mit virtuellen Streams von Project Loom.



Da viel Code die alte API verwendet (seit JDK 1.0), wird die veraltete Implementierung nicht entfernt. Tatsächlich konfiguriert eine neue JDK-spezifische Systemeigenschaft, jdk.net.usePlainDatagramSocketImpl, das JDK so, dass eine veraltete Implementierung verwendet wird, wenn API-Refactoring Probleme bei Regressionstests oder in einigen Fällen verursacht.

Wir freuen uns auf neue Produkte

Versiegelte Klassen ( JEP 360 ). Die erste in Project Amber erstellte Entwurfsversion. Versiegelte Klassen und Schnittstellen beschränken ihre Erweiterung oder Implementierung auf andere Klassen. Warum ist es wichtig? Ein Entwickler möchte möglicherweise Code verwalten, der für die Implementierung einer bestimmten Klasse oder Schnittstelle verantwortlich ist. Versiegelte Klassen bieten eine deklarativere Möglichkeit als Zugriffsmodifikatoren, um die Verwendung der Oberklasse einzuschränken. Zum Beispiel:





Der Zweck des Versiegelns einer Klasse besteht darin, dem Clientcode mitzuteilen, welche Unterklassen zulässig sind. Schließlich kann es Anwendungsfälle geben, in denen erwartet wird, dass die ursprüngliche Definition einer Klasse (oder Schnittstelle) vollständig ist, und in denen der Entwickler nicht zulässt, dass sie außer Kontrolle gerät - nur explizit angegebene Klassen können dies.



Es gibt einige Einschränkungen für versiegelte Klassen:

• Die versiegelte Klasse und ihre zulässigen Unterklassen müssen sich im selben Modul befinden. Wenn sie in einem unbenannten Modul deklariert sind, müssen sie im selben Paket abgelegt werden
• Jede erlaubte Unterklasse muss die versiegelte Klasse direkt erweitern
• , , , — final, sealed nonsealed ( )

Mustervergleich zum Beispiel ( JEP 375 ). Die zweite Vorschau ist eine weitere Entwicklung von Project Amber. Die erste vorläufige Version der Funktionalität war in Java 14 und es gibt keine Änderungen im Vergleich dazu.



Ziel ist es, Java durch Pattern Matching für die Instanz des Operators zu verbessern. Auf diese Weise können Sie die allgemeine Logik im Programm, nämlich das bedingte Extrahieren von Komponenten aus Objekten, präziser und sicherer ausdrücken. Lassen Sie mich als Beispiel auf Mal Guptas hervorragenden Artikel " Pattern Matching zum Beispiel in Java 14 " verweisen .



Einträge ( JEP 384), zweiter Entwurf. Datensätze sind Klassen, die als transparente Träger unveränderlicher Daten fungieren. Das neue JEP enthält Erläuterungen auf der Grundlage von Community-Feedback und unterstützt mehrere neue zusätzliche Formen lokaler Klassen und Schnittstellen. Die Beiträge stammen auch aus dem Projekt Amber.



Datensätze sind ein objektorientiertes Konstrukt, das eine einfache Aggregation von Werten ausdrückt. Daher helfen sie Programmierern, sich auf die Modellierung unveränderlicher Daten anstatt auf erweiterbares Verhalten zu konzentrieren. Datensätze implementieren automatisch datengesteuerte Methoden wie Equals und Accessors. Die Einträge bewahren auch langjährige Java-Prinzipien wie nominelle Typisierung und Migrationskompatibilität. Mit anderen Worten, sie erleichtern das Codieren und Lesen von Klassen, die unveränderliche Daten enthalten.



Externer Speicherzugriff ( JEP 383 ) ist die zweite Inkubatorversion der API, mit der Java-Programme sicher und effizient auf externen Speicher außerhalb des Java-Heaps zugreifen können. Ziel ist es, java.nio.ByteBuffer und sun.misc.Unsafe zu ersetzen. Es ist Teil des Panama-Projekts, das die Kommunikation zwischen Java und anderen APIs verbessert.



Der JEP beschreibt die Notwendigkeit dieser Innovation treffend wie folgt:



Wenn es um den Zugriff auf externen Speicher geht, stehen Entwickler vor einem Dilemma - sollten sie einen sicheren, aber begrenzten (und möglicherweise weniger effizienten) Pfad wie die ByteBuffer-API wählen oder sollten sie Sicherheitsgarantien aufgeben und eine gefährliche und nicht unterstützte unsichere API einführen?



Mit diesem JEP wird eine sichere, wartbare und effiziente API für den Zugriff auf externen Speicher eingeführt. Durch die Bereitstellung einer gezielten Lösung für das Problem des externen Speicherzugriffs werden Entwickler von den Einschränkungen und Gefahren vorhandener APIs befreit. Sie werden auch eine bessere Leistung erzielen, da die neue API unter Berücksichtigung der JIT-Optimierungen von Grund auf neu entwickelt wurde.

Entfernung und Ende der Unterstützung

Keine dieser Entscheidungen sollte kontrovers sein.



Entfernen der Nashorn JavaScript Engine ( JEP 372 ). Diese Engine, ihre API und das jjs-Tool waren in Java 11 veraltet. Es ist Zeit, sich zu verabschieden.



Durch Deaktivieren und Eliminieren der reservierten Sperre ( JEP 374 ) wird die alte Optimierungstechnik entfernt, die in der HotSpot-JVM verwendet wird, um den mit der nicht aktivierten Sperre verbundenen Overhead zu verringern. Diese Sperrung hat in der Vergangenheit zu erheblichen Leistungsverbesserungen gegenüber herkömmlichen Sperrmethoden geführt, aber die in der Vergangenheit beobachteten Leistungssteigerungen sind heute viel weniger offensichtlich. Die Kosten für die Ausführung atomarer Anweisungen auf modernen Prozessoren sind gesunken.



Redundantes Sperren hat zu viel komplexem Code geführt, und diese Komplexität verhindert, dass das Java-Entwicklungsteam wesentliche Änderungen an der Synchronisations-Engine vornimmt. Durch Deaktivieren der Sperre und Überlassen der Sperre durch den Programmierer hofft das Java-Team zu entscheiden, ob es sinnvoll ist, sie in einer zukünftigen Version vollständig zu entfernen.



Entfernen von Solaris- und SPARC-Ports ( JEP 381 ). In diesem Fall wird der gesamte für das Solaris-Betriebssystem und die SPARC-Architektur spezifische Quellcode entfernt. Mehr gibt es nicht zu sagen.



Schließen Sie die RMI-Aktivierung für eine spätere Deinstallation aus ( JEP 385)). Vereinfacht Java, indem der veraltete Teil des Aufrufs von Remotemethoden entfernt wird, der in Java 8 optional war.



Die Verwendung der RMI-Aktivierung wird reduziert und reduziert. Das Java-Team sieht keine Hinweise darauf, dass neue Anwendungen damit geschrieben wurden, und es gibt Hinweise darauf, dass nur sehr wenige vorhandene Anwendungen die RMI-Aktivierung verwenden. Bei der Suche in verschiedenen Open Source-Codebasen wurden fast keine damit verbundenen APIs erwähnt. Seit mehreren Jahren gibt es keine Berichte über extern generierte RMI-Aktivierungsfehler.



Die Unterstützung der RMI-Aktivierung als Teil der Java-Plattform verursacht laufende Wartungskosten. Dies erhöht die Komplexität des RMI. Sie können die RMI-Aktivierung entfernen, ohne den Rest des RMI zu beeinflussen. Durch das Entfernen wird der Entwicklerwert von Java nicht verringert, aber die langfristigen Wartungskosten des JDK.

Fazit

Java 15 setzt seinen sechsmonatigen Release-Zyklus fort und ist ein mittelgroßes Release, das für die meisten Entwickler nützlich ist.