Die Probleme der Welt sind die Probleme der Welt, und das neue Java liegt im Zeitplan. Das heißt, genau alle sechs Monate. Die Release-Version von Java 14 wurde am 17. März veröffentlicht und führte mehrere interessante Neuerungen in der Sprache ein, die sich an Entwickler richteten. Dazu gehören experimentelle Unterstützung für das Schlüsselwort „ record“ , Unterstützung für Mustervergleich im Operator „ instanceof “, benutzerfreundlichere NullPointerExceptions , erweiterte „Vorschau“ von Textblöcken , ein aktualisierter Standardschalter und vieles mehr. Wir möchten Sie daran erinnern, dass alle Innovationen in Java mit Erweiterungsvorschlägen ( JEP, Java Enhancement Proposals ) beginnen. Entwickler schlagen Änderungen vor, sie werden von den „offiziellen“ Java-Eltern überprüft und dann werden einige dieser Änderungen akzeptiert, woraufhin sie Teil des JDK werden. Und jetzt - alles in Ordnung.
Records, auch Records genannt, stehen für JDK 14 im Vorschaumodus zur Verfügung, was für Java etwas völlig Neues ist. Tatsächlich haben wir einen neuen Typ vor uns, der während des Valhalla- Projekts entwickelt wurde . Datensätze ähneln Aufzählungen und ermöglichen Ihnen, Ihren Code zu vereinfachen. Im Wesentlichen ersetzen sie Klassen, die einen Status, aber kein Verhalten haben. Einfach ausgedrückt: Es gibt Felder, keine Methoden. Bei Klassen müssen wir manchmal viel sich wiederholenden Code schreiben, der nicht immer notwendig ist: Konstruktoren, Accessoren, equal(), hashCode(), toString() usw. Um diesen sich wiederholenden Code zu vermeiden, plant Java Aufnahme verwenden. Hier ist die klassische Version:
Das ist alles. Bitte beachten Sie, dass die Aufnahmen derzeit in Vorschauform vorliegen. Um sie in der Praxis auszuprobieren, müssen Sie jdk14 herunterladen und den folgenden Befehl eingeben:
javac —enable-preview —release 14Triangle.java
Datensätze sind Klassen, allerdings mit Einschränkungen. Sie können keine anderen Klassen erweitern oder Felder deklarieren (außer private final, die Zustandsdeklarationskomponenten entsprechen). Aufzeichnungen sind implizit endgültig und können nicht abstrakt sein. Datensätze unterscheiden sich von regulären Klassen dadurch, dass sie ihre API nicht von ihrer Darstellung trennen können. Der Freiheitsverlust wird jedoch durch eine erhöhte Genauigkeit ausgeglichen. Datensatzkomponenten sind implizit ebenfalls endgültig.
Die Funktion „Pattern Matching“ , die in Java 14 in der Vorschau eingeführt wurde, soll die Prüfung des Typs eines Objekts und seine Konvertierung im Instanzoperator kombinieren. Mit anderen Worten: Vor Java 14 hätte es beispielsweise folgenden Code gegeben:
Wie Sie sehen, müssen wir das Objekt in die Klasse umwandeln, deren Methoden wir verwenden möchten. Jetzt können Sie mit Java 14 und der damit verbundenen Mustervergleichsfunktion den Code wie folgt reduzieren:
JDK 8 verfügte über ein Javapackager- Tool , das für JavaFX entwickelt wurde. Nach der Trennung von JavaFX von Java mit der Veröffentlichung von JDK 11 war der beliebte Javapackager jedoch nicht mehr verfügbar. Javapackager war ein Paketierungstool. Dadurch konnten Java-Anwendungen so verpackt werden, dass sie wie alle anderen „normalen“ Programme installiert werden konnten. Erstellen Sie beispielsweise Exe-Dateien für Windows-Benutzer und starten Sie eine Java-Anwendung wie ein Mensch – mit einem Doppelklick. Natürlich fehlt ein solches Tool schmerzlich, daher führte JEP 343 ein neues Tool ein, jpackage , das eine Java-Anwendung in ein plattformspezifisches Paket packt, das alle notwendigen Abhängigkeiten enthält. Unterstützte Paketformate für eine bestimmte Plattform:
JEP 345 dient ausschließlich der Implementierung der NUMA-Unterstützung (Non-Uniform Memory Access). Hierbei handelt es sich um heterogene Speicherzugriffsarchitekturen, eine Möglichkeit, einen Mikroprozessor-Cluster zu einem Multiprozessorsystem zusammenzustellen, in dem der Speicher lokal verteilt werden kann: Jeder Prozessorkern erhält eine kleine Menge lokalen Speichers, während andere Kerne Zugriff darauf haben. JEP 345 plant, den G1-Garbage Collector mit der Fähigkeit auszustatten, solche Architekturen zu nutzen. Dieser Ansatz trägt unter anderem dazu bei, die Leistung auf sehr leistungsstarken Maschinen zu verbessern.
Java Flight Recorder (JFR) ist jetzt Teil von OpenJDK und daher frei verfügbar. JDK 14 fügt eine API zur On-the-Fly-Verfolgung von JFR-Ereignissen (JDK Flight Recorder) hinzu, insbesondere zur Organisation der kontinuierlichen Überwachung aktiver und inaktiver Anwendungen. Es werden die gleichen Ereignisse aufgezeichnet wie bei der Nicht-Streaming-Option, mit einem Overhead von weniger als 1 %. Auf diese Weise werden die Ereignisse gleichzeitig mit der Nicht-Streaming-Option gestreamt. JEP 349 darf jedoch keine synchronen Rückrufe für den entsprechenden Verbraucher zulassen. Auch Daten aus im Zwischenspeicher abgelegten Datensätzen sollten nicht zugänglich sein. Technisch gesehen wird das Paket jdk.jfr.consumer im Modul jdk.jfr um Funktionen für den asynchronen Zugriff auf Ereignisse erweitert.
Wie wir wissen, gibt es die Java NIO (New IO) File API seit JDK 1.4, und dann wurde eine neue Erweiterung namens Path eingeführt. Path ist eine Schnittstelle, die die Klasse java.io.File als Darstellung einer Datei oder eines Verzeichnisses ersetzt, wenn wir in Java NIO arbeiten. JEP 352 erweitert MappedByteBuffer, um einen Teil der Dateidaten in den nichtflüchtigen Speicher (NVM) zu laden. Dieser Computerspeicher, in dem Daten auch dann nicht verloren gehen, wenn der Strom ausgeschaltet wird (oft als persistenter Speicher bezeichnet), dient der dauerhaften Speicherung von Daten. Dieser Java-Erweiterungsvorschlag stellt ein neues Modul und eine neue Klasse für die JDK-API bereit: das Modul jdk.nio.mapmode, das neue Modi (READ_ONLY_SYNC, WRITE_ONLY_SYNC) zum Erstellen zugeordneter Bytepuffer (MappedByteBuffer) bietet, die auf NVM verweisen.
NullPointerExceptions werden jetzt programmiererfreundlicher sein. In dem Sinne, dass die Beschreibung der Ausnahme viel informativer sein wird als zuvor. Dies liegt daran, dass der JVM beigebracht wurde, Programm-Bytecode-Anweisungen genauer zu analysieren, und dass sie angeben kann, welche Variable zu einem Nullwert führt. Nehmen wir an, wir haben den Code:
a.getMessage().getUserInfo().getName()
In jedem der neuesten Java-Versionen erhalten wir das übliche Fehlerprotokoll, das die Frage, wer genau null ist, nicht beantwortet:
Exception in thread "main"java.lang.NullPointerException
at Main.main(Main.java:12)
Und das bietet Ihnen Java 14, wenn Sie sich entscheiden, diese Vorschaufunktion auszuprobieren:
Exception in thread "main"java.lang.NullPointerException:Cannot invoke "UserInfo().getName()" because the return value of "Message().getUserInfo()" is null
at Main.main(Main.java:12)
Diese Kette ist viel verständlicher und ermöglicht es Ihnen, den Fehler viel schneller zu beheben.
Der aktualisierte Switch-Operator war in früheren Versionen von Java 12 und 13 verfügbar, jedoch nur als Vorschaufunktion, d. h. er war nicht standardmäßig aktiviert. Jetzt funktioniert in JDK 14 alles sofort. Java 14 führt eine neue vereinfachte Form des Switch-Blocks mit den Beschriftungen case L -> ... ein. Die neue Form vereinfacht den Code in einigen Fällen. Hier sind ein paar Beispiele. Nehmen wir an, wir haben eine Aufzählung, die die Wochentage beschreibt. Wir können klassischen Code schreiben (vor Java 14):
Sie können auch mehrzeilige Blöcke schreiben und einen Wert mit dem neuen Schlüsselwort yield zurückgeben:
int result =switch(s){case"Working from Home"->1;case"Working from Office"->2;default->{System.out.println("Neither Home nor Office… Cafe? Car? Park?...");yield0;}};
Bei der Verwendung der neuen Schalter sind noch einige weitere wichtige Dinge zu beachten . Insbesondere müssen Sie bedenken, dass die Optionen erschöpfend sein müssen. Das heißt, für alle möglichen Werte muss eine entsprechende Schalterbeschriftung vorhanden sein. Da yield jetzt ein Schlüsselwort ist, ist in Java 14 eine Klasse namens yield möglich. Wenn Sie im Allgemeinen lernen möchten, wie Sie die aktualisierten Schalter verwenden, gehen Sie zu JEP 361 und studieren Sie. Da gibt es viele interessante Informationen.
Es ist unwahrscheinlich, dass sich viele unserer Leser an das Betriebssystem Solaris erinnern . Dieses UNIX-basierte Betriebssystem, das von Sun Microsystems, den Eltern von Java, entwickelt wurde, wurde hauptsächlich für Server auf der SPARC-Architektur verwendet ... Zu viele unbekannte Wörter pro Quadratzentimeter? Keine große Sache: JEP 362 beendet die Unterstützung für die Plattformen Solaris/SPARC, Solaris/x64 und Linux/SPARC. Das heißt, ihre Ports sind jetzt veraltet und werden höchstwahrscheinlich in Zukunft aus OpenJDK entfernt. Ältere Java-Versionen (vor JDK 14) in Bezug auf die Ports Solaris/SPARC, Solaris/x64 und Linux/SPARC sollten jedoch ohne Änderungen funktionieren. Wenn Sie ein Geschichtsinteressierter sind und sich für Technologien aus nicht allzu ferner Vergangenheit interessieren, gehen Sie zu Wikipedia und lesen Sie mehr über die SPARS- Architektur .
Der CMS-Garbage Collector (Concurrent Mark Sweep) soll entfernt werden, da er vor zwei Jahren als veraltet markiert und nicht mehr gewartet wurde. Benutzer älterer Java-Versionen, die das CMS GC verwenden, können jedoch aufatmen – der Zweck dieses JEP besteht nicht darin, den Builder aus früheren JDK-Versionen zu entfernen. Darüber hinaus ist die Kombination der Garbage-Collection-Algorithmen ParallelScavenge und SerialOld (ausgeführt mit den Optionen „-XX:+UseParallelGC -XX:-UseParallelOldGC“) veraltet.
Es gibt einen interessanten Garbage Collector namens Z Garbage Collector (ZGC) . Es arbeitet im passiven Modus und versucht, Verzögerungen aufgrund der Speicherbereinigung zu minimieren: Die Stoppzeit bei Verwendung von ZGC überschreitet nicht 10 ms. Es kann mit kleinen und riesigen Heaps (die viele Terabyte belegen) arbeiten. JEP 364 und JEP 365 sind praktisch Zwillinge. JEP 364 bringt Z Garbage Collector auf MacOS. Ein Teil des JEP beschreibt auch die Collector-Funktionalität zum Freigeben von ungenutztem Gerätespeicher, wie in JEP 351 angegeben . Dies geschieht seit Java 13. Die ZGC-Implementierung auf macOS besteht aus zwei Teilen:
Multi-Mapping-Speicherunterstützung unter macOS
ZGC-Unterstützung für kontinuierliche Speicherreservierung
JEP 365 bietet Unterstützung für ZGC bereits unter Windows und auch im experimentellen Modus. Es ist wie folgt:
Unterstützung für Multi-Mapping-Speicher
Unterstützung für die Speicherzuordnung basierend auf der Auslagerungsdatei in einen reservierten Adressraum
Unterstützung für das Zuordnen und Aufheben der Zuordnung beliebiger Teile des Heaps
Unterstützung für das Festschreiben und Aufheben der Festschreibung beliebiger Teile des Heaps
Dieses JEP lehnt die Kombination der Garbage-Collection-Algorithmen Parallel Scavenge und Serial Old ab. Diese Kombination musste manuell mit den Befehlszeilenparametern -XX: + UseParallelGC -XX: -UseParallelOldGC aktiviert werden. Nach Ansicht der Autoren ist die Kombination sehr spezifisch, erfordert aber auch einen erheblichen Wartungsaufwand. Daher ist die Option -XX: UseParallelOldGC jetzt veraltet und bei Verwendung wird eine Warnung angezeigt.
Pack200 ist ein Archivformat, das für die Speicherung kompilierter Java-Klassendateien optimiert ist. Dieses Tool gilt seit Java 11 als veraltet. Nun wurde die Entfernung der API-Tools pack200, unpack200 und Pack200 offiziell aus dem Paket java.util.jar angekündigt . Diese Technologie wurde bereits in Java 5 eingeführt, um mit der sehr begrenzten Bandbreite (beängstigenderweise 56 KB bei Modems) und unzureichendem Speicherplatz auf Festplatten umzugehen. Vor einiger Zeit wurden mit Java 9 neue Komprimierungsschemata eingeführt. Entwicklern wird empfohlen, jlink zu verwenden .
Textblöcke tauchten erstmals in Java 13 auf. Dabei handelt es sich um mehrzeilige String-Literale, die die meisten Escape-Sequenzen überflüssig machen, den String automatisch formatieren und es dem Entwickler auch ermöglichen, den String bei Bedarf zu formatieren. Diese nützliche Funktion ist jetzt in Java 14 (2. Vorschau) verfügbar. Der Hauptzweck von Textblöcken besteht darin, die Handhabung verwirrender mehrzeiliger Literale zu verbessern. Dies vereinfacht das Lesen und Schreiben von SQL-Abfragen, HTML- und XML-Code sowie JSON erheblich. Beispiel-HTML ohne Textblöcke:
String html ="<html>\n"+" <body>\n"+" <p>Hello, JavaRush Student</p>\n"+" </body>\n"+"</html>\n";
Das öffnende Trennzeichen ist eine Folge von drei doppelten Anführungszeichen („““), gefolgt von null oder mehr Leerzeichen und dann einem Zeilentrennzeichen. Der Inhalt beginnt beim ersten Zeichen nach dem Zeilentrennzeichen des öffnenden Trennzeichens. Das schließende Trennzeichen ist Eine Folge von drei doppelten Anführungszeichen „ _ ) wurde gewählt, damit die Zeichen ohne Escapezeichen angezeigt werden können und außerdem einen Textblock optisch von einem Zeichenfolgenliteral unterscheiden können. Anfang 2019 schlug JEP 355 Textblöcke als Fortsetzung von JEP 326 (Raw String Literals) vor, die jedoch zurückgezogen wurden. Später in diesem Jahr führte JDK 13 die Textblock-Vorschaufunktion ein, und jetzt hat Java 14 zwei neue Escape-Sequenzen hinzugefügt. Dies ist ein Zeilenabschlusszeichen mit der Bezeichnung \, und das zweite steht für ein einzelnes Leerzeichen mit der Bezeichnung /s. Ein Beispiel für die Verwendung von Zeilenumbrüchen ohne Textblöcke:
String literal ="This is major Tom to Ground Control "+"I am stepping through the door... "+"Wait… What???";
Und nun mit der Escape-Sequenz \<line-terminator>:
String text ="""
This is major TomtoGroundControl \
I am stepping through the door... \
Wait… What???\
""";
Die Escape-Sequenz \s wird verwendet, um nachfolgende Leerzeichen zu berücksichtigen, die vom Compiler standardmäßig ignoriert werden. Es behält alle vorangehenden Leerzeichen bei. Beispiel:
Viele beliebte Java-Bibliotheken und -Programme haben Zugriff auf externen Speicher. Zum Beispiel Ignite, MapDB, Memcached und Netty ByteBuf API. Auf diese Weise können sie die mit der Garbage Collection verbundenen Kosten und Unvorhersehbarkeiten vermeiden (insbesondere bei der Bereitstellung großer Caches), den Speicher für mehrere Prozesse gemeinsam nutzen und Speicherinhalte serialisieren und deserialisieren, indem sie Dateien im Speicher zuordnen (z. B. mithilfe von mmap). Für den Zugriff auf externen Speicher verfügt die Java-API allerdings noch nicht über eine passende Lösung. JDK 14 enthält eine Vorschau der Foreign-Memory Access API , die es Java-Anwendungen ermöglicht, mithilfe der neuen Abstraktionen MemorySegment, MemoryAddress und MemoryLayout sicher und effizient auf Speicherbereiche außerhalb des JVM-Heaps zuzugreifen.
Schlussfolgerungen
Also was denkst du? Im Vergleich zu Java 13 bietet das neue Java 14 viele weitere wichtige Verbesserungen in verschiedenen Bereichen. Am wichtigsten für Entwickler werden höchstwahrscheinlich der aktualisierte Schalter, die erweiterten Ausnahmen NullPointerExceptions und Datensätze sein. Oder nicht? Vergessen Sie nicht, die neuen Funktionen von Java 14 auszuprobieren, es ist auch für Anfänger sehr nützlich. Viel Erfolg beim Studium!
GO TO FULL VERSION