📖 🏈 ⚔️ 90 neue Funktionen (und APIs) in JDK 11 💅🏻 🚧 👩🏿‍⚕️

Hallo Habr! Ich präsentiere Ihnen die Übersetzung des Artikels „ 90 neue Funktionen (und APIs) in JDK 11 “ von Simon Ritter.

Für viele bedeutet der neue sechsmonatige JDK-Veröffentlichungszyklus, dass einige noch nicht herausgefunden haben, welche neuen Funktionen in JDK 10 enthalten sind, und JDK 11 kurz davor steht. In einem der frühen Blogs wurden alle 109 neuen Funktionen und APIs aufgelistet konnte in JDK 10 gefunden werden. Daher wurde für JDK 11 beschlossen, dasselbe zu tun. Es wurde jedoch ein anderes Format gewählt. Dieser Beitrag wird in zwei Abschnitte unterteilt: neue Funktionen, die Entwicklern zur Verfügung stehen (öffentliche API) und alles andere. Wenn Sie also nur daran interessiert sind, was sich direkt auf Ihre Entwicklung auswirkt, können Sie den zweiten Teil überspringen.

Die Gesamtzahl der Änderungen, die berechnet werden konnten, betrug 90 (dies ist JEP plus neue Klassen und Methoden, ausgenommen separate Methoden für den HTTP-Client und den Flight Recorder ) ( Anmerkung des Übersetzers: Java Flight Recorder (JFR) war eines der in Oracle integrierten Add-Ons im JDK, aber ab Java 11 wurde es dank JEP 328 auf Open Source übertragen) . Obwohl JDK 11 elf Änderungen weniger als in JDK 10 gefunden hat, kann man mit Recht sagen, dass JDK 11 definitiv auf JVM-Ebene um mehr Funktionen erweitert wurde.

Neue Funktionen, die für den Entwickler erkennbar sind

JDK 11 enthält einige Änderungen, die sich auf den Entwicklungsstil auswirken können. Es gibt eine geringfügige Änderung der Syntax, viele neue APIs und die Möglichkeit, Anwendungen in einer Datei ohne Verwendung eines Compilers auszuführen ( Hinweisübersetzer: sogenannte Shebang-Dateien ). Darüber hinaus ist die große (und wichtige ) Änderung das Entfernen des Aggregationsmoduls java.se.ee , das sich auf die Migration einer vorhandenen Anwendung auf JDK 11 auswirken kann.

JEP 323: Syntax lokaler Variablen für Lambda-Parameter

In JDK 10 wurde die lokale Variableninferenz (oder Typinferenz) eingeführt ( JEP 286 ). Dies vereinfacht den Code, da Sie den Typ der lokalen Variablen nicht mehr explizit angeben müssen, sondern stattdessen var verwenden können. JEP 323 erweitert die Verwendung dieser Syntax, die jetzt auch auf die Parameter von Lambda-Ausdrücken anwendbar ist. Ein einfaches Beispiel:

list.stream() .map((var s) -> s.toLowerCase()) .collect(Collectors.toList());

Ein aufmerksamer Java-Programmierer würde angeben, dass Lambda-Ausdrücke bereits Typinferenz haben, sodass die Verwendung von var (in diesem Fall) redundant wäre. Wir könnten genauso gut den gleichen Code schreiben wie:

  list.stream() .map(s -> s.toLowerCase()) .collect(Collectors.toList());

Warum Var-Unterstützung hinzufügen? Die Antwort ist ein Sonderfall - wenn Sie einem Lambda-Parameter eine Anmerkung hinzufügen möchten. Dies kann nicht ohne irgendeine Beteiligung geschehen. Um die Verwendung eines expliziten Typs zu vermeiden, können wir var verwenden, um die Dinge auf folgende Weise zu vereinfachen:

  list.stream() .map((@Notnull var s) -> s.toLowerCase()) .collect(Collectors.toList());

Diese Änderung erforderte Änderungen an der Java Language Specification (JLS) , insbesondere:

Seite 24: Die Beschreibung der var-Spezialkennung.
Seite 627-630: Lambda-Parameter
Seite 636: Laufzeitauswertung von Lambda-Ausdrücken
Seite 746: Lambda-Syntax

JEP 330: Starten von Single-File-Quellcode-Programmen

Eine der Kritikpunkte an Java ist die Redundanz der Syntax, und die „Zeremonie“, die mit dem Starten selbst einer trivialen Anwendung verbunden ist, kann die Einstiegsschwelle für Anfänger erheblich erhöhen. Um eine Anwendung zu schreiben, die einfach "Hello World!" Druckt, müssen Sie eine Klasse mit der öffentlichen statischen void main-Methode schreiben und die System.out.println () -Methode verwenden. Anschließend müssen Sie den Code mit javac kompilieren. Schließlich können Sie eine Anwendung starten, die die Welt willkommen heißt. Das Ausführen des gleichen Skripts in den meisten modernen Sprachen ist viel einfacher und schneller.

JEP 330 macht das Kompilieren einer Einzeldateianwendung überflüssig. Geben Sie jetzt einfach ein:

  java HelloWorld.java

Der Java-Launcher erkennt, dass die Datei den Java-Quellcode enthält, und kompiliert den Code vor der Ausführung in eine * .class-Datei.

Nach dem Namen der Quelldatei platzierte Argumente werden beim Start der Anwendung als Argumente übergeben. Argumente, die vor dem Namen der Quelldatei stehen, werden nach dem Kompilieren des Codes als Argumente an den Java-Launcher übergeben (auf diese Weise können Sie beispielsweise den Klassenpfad in der Befehlszeile festlegen). Argumente, die sich auf den Compiler beziehen (z. B. Klassenpfad), werden ebenfalls zur Kompilierung an javac übergeben.

Ein Beispiel:

  java -classpath /home/foo/java Hello.java Bonjour

Es entspricht:

  javac -classpath /home/foo/java Hello.java java -classpath /home/foo/java Hello Bonjour

Dieses JEP bietet auch Unterstützung für Shebang-Dateien. Um zu vermeiden, dass der Java-Launcher in der Befehlszeile erwähnt werden muss, können Sie ihn in die erste Zeile der Quelldatei aufnehmen. Zum Beispiel:

  #!/usr/bin/java --source 11 public class HelloWorld { ...

Das Flag -source mit der verwendeten Java-Version ist erforderlich.

JEP 321: HTTP-Client (Standard)

JDK 9 führte eine neue API zur Unterstützung des HTTP-Client-Protokolls ( JEP 110 ) ein. Da JDK 9 das Java Platform Module System (JPMS) bereitstellte , wurde diese API als Inkubatormodul aufgenommen . Inkubatormodule bieten neue APIs, machen sie jedoch nicht zum Java SE-Standard. Entwickler können die API testen, indem sie Feedback geben. Nach den erforderlichen Änderungen (diese API wurde in JDK 10 aktualisiert) kann die API auf das Hauptmodul übertragen werden, um Teil des Standards zu werden.

Die HTTP-Client-API ist jetzt Teil des Java SE 11-Standards. Damit wird ein neues Modul und Paket für das JDK, java.net.http, eingeführt . Hauptklassen:

Httpclient
Httprequest
HttpResponse
Web-Socket

Die API kann synchron oder asynchron verwendet werden. Im asynchronen Modus werden CompletionFutures und CompletionStages verwendet.

JEP 320: Entfernen Sie die Java EE- und CORBA-Module

Mit der Einführung von JPMS in JDK 9 war es möglich, die monolithische Datei rt.jar in mehrere Module aufzuteilen. Ein zusätzlicher Vorteil von JPMS besteht darin, dass Sie jetzt eine Java-Laufzeitumgebung erstellen können, die nur die für Ihre Anwendung erforderlichen Module enthält, wodurch die Gesamtgröße erheblich reduziert wird. Mit klar definierten Grenzen lassen sich veraltete Module jetzt einfacher aus der Java-API entfernen. Dies ist, was dieser JEP tut; Das Metamodul java.se.ee enthält sechs Module, die nicht mehr Teil des Java SE 11-Standards sind und nicht im JDK enthalten sind.

Remote-Module:

corba ( Anmerkung des Übersetzers: ~~Ruhe in Frieden~~ in der Hölle brennen )
Transaktion
Aktivierung
xml.bind
xml.ws
xml.ws.annotation

Diese Module sind seit JDK 9 als veraltet (@Deprecated) markiert und wurden standardmäßig nicht in die Kompilierung oder Laufzeit einbezogen. Wenn Sie versucht hätten, eine Anwendung mithilfe der API aus diesen Modulen in JDK 9 oder JDK 10 zu kompilieren oder auszuführen, wären Sie gescheitert. Wenn Sie die API dieser Module in Ihrem Code verwenden, müssen Sie sie als separates Modul oder Bibliothek bereitstellen. Den Bewertungen nach zu urteilen, scheinen die java.xml-Module, die Teil der Unterstützung von JAX-WS, SOAP-Webdiensten sind, die meisten Probleme zu verursachen.

Neue öffentliche API

Viele der neuen APIs in JDK 11 sind das Ergebnis der Tatsache, dass das HTTP-Client-Modul jetzt Teil des Standards ist, sowie der Integration von Flight Recorder.

Eine vollständige schematische Liste der API-Änderungen, einschließlich eines Vergleichs verschiedener Versionen des JDK, finden Sie hier.

Hier sind alle neuen Methoden aufgeführt, die nicht in den Modulen java.net.http und jdk.jfr enthalten sind. Ebenfalls nicht aufgeführt sind die neuen Methoden und Klassen in den Modulen java.security, die für Änderungen von JEP 324 und JEP 329 sehr spezifisch sind (es gibt sechs neue Klassen und acht neue Methoden).

java.io.ByteArrayOutputStream

void writeBytes (byte []) : Schreibt alle Bytes aus dem Argument in OutputStream

java.io.FileReader

Zwei neue Konstruktoren, mit denen Sie einen Zeichensatz angeben können.

java.io.FileWriter

Vier neue Konstruktoren, mit denen Sie einen Zeichensatz angeben können.

java.io.InputStream

io.InputStream nullInputStream () : Gibt einen InputStream zurück, der keine Bytes liest. Bei Betrachtung dieser Methode (und der in OutputStream, Reader und Writer) stellt sich die Frage, warum sie nützlich sein könnte. Sie können sie sich als / dev / null vorstellen, um nicht benötigte Ausgaben zu verwerfen oder Eingaben bereitzustellen, die immer Null-Bytes zurückgeben.

java.io.OutputStream

io.OutputStream nullOutputStream ()

java.io.Reader

io.Reader nullReader ()

java.io.Writer

io.Writer nullWriter ()

java.lang.Character

String toString (int) : Dies ist eine überladene Form einer vorhandenen Methode, aber int wird anstelle von char verwendet. Int ist der Unicode-Codepunkt.

java.lang.CharSequence

int compare (CharSequence, CharSequence) : Vergleicht zwei lexikografische Instanzen von CharSequence. Gibt einen negativen Wert, Null oder einen positiven Wert zurück, wenn die erste Sequenz lexikographisch kleiner, gleich oder größer als die zweite ist.

java.lang.ref.Reference

lang.Object clone () : Ich muss zugeben, diese Änderung sorgt für Verwirrung. Die Reference-Klasse implementiert die klonbare Schnittstelle nicht, und diese Methode löst eine CloneNotSupportedException aus. Es muss einen Grund für seine Aufnahme geben, vielleicht für etwas in der Zukunft. ( Anmerkung des Übersetzers: Es gibt eine Diskussion über StackOverflow , ein Ticket in OpenJDK. )

java.lang.Runtime

java.lang.System

Es gibt hier keine neuen Methoden, aber es ist erwähnenswert, dass die runFinalizersOnExit () -Methode jetzt aus beiden Klassen entfernt wurde (bei der Migration auf JDK 11 kann ein Problem auftreten).

java.lang.String

Ich denke, dies ist eines der Highlights der neuen APIs in JDK 11. Hier gibt es einige nützliche neue Methoden.

boolean isBlank () : Gibt true zurück, wenn die Zeichenfolge leer ist oder nur Leerzeichen enthält, andernfalls false.
Stream lines () : Gibt Stream from String zurück, der aus diesem String extrahiert und durch Zeilentrennzeichen getrennt wurde.
String repeat (int) : Gibt einen String zurück, dessen Wert die Verkettung dieses Strings ist, der mehrmals wiederholt wird.
String strip () : Gibt einen String zurück, dessen Wert dieser String ist. Dadurch werden alle Leerzeichen am Anfang und Ende des Strings entfernt.
String stripLeading () : Gibt einen String zurück, dessen Wert dieser String ist, während alle Leerzeichen am Zeilenanfang entfernt werden.
String stripTrailing () : Gibt einen String zurück, dessen Wert dieser String ist. Dadurch werden alle Leerzeichen am Ende des Strings entfernt.

Höchstwahrscheinlich schauen Sie sich strip () an und fragen: "Wie unterscheidet sich das von der vorhandenen trim () -Methode?" Die Antwort liegt in der unterschiedlichen Definition von Räumen. ( Anmerkung des Übersetzers: Kurz gesagt, strip () versteht Unicode besser, detaillierte Analyse auf StackOverflow )

java.lang.StringBuffer

java.lang.StringBuilder

Beide Klassen haben eine neue compareTo () -Methode, die einen StringBuffer / StringBuilder verwendet und einen int zurückgibt. Die lexikalische Vergleichsmethode ähnelt der neuen compareTo () -Methode in CharSequence.

java.lang.Thread

Keine neuen Methoden. Die Methoden destroy () und stop (Throwable) wurden entfernt. Die stop () -Methode, die keine Argumente akzeptiert, ist noch vorhanden. Kann zu einem Kompatibilitätsproblem führen.

java.nio.ByteBuffer

java.nio.CharBuffer

java.nio.DoubleBuffer

java.nio.FloatBuffer

java.nio.LongBuffer

java.nio.ShortBuffer

Alle diese Klassen haben jetzt die Methode mismatch () , die den relativen Index der ersten Nichtübereinstimmung zwischen diesem Puffer und dem übergebenen Puffer findet und zurückgibt.

java.nio.channels.SelectionKey

int InterestOpsAnd (int) : Legt das Interesse dieses Schlüssels (das Interesse des Schlüssels ) atomar an der bitweisen Schnittmenge ("und") der vorhandenen Interessengruppe und des übergebenen Werts fest.
int InterestOpsOr (int) : Legt das Interesse dieses Schlüssels (das Interesse des Schlüssels ) atomar an der bitweisen Vereinigung ("oder") der vorhandenen Interessengruppe und des übergebenen Werts fest.

java.nio.channels.Selector

int select (java.util.function.Consumer, long) : Wählen Sie Aktionen für Tasten aus und führen Sie sie aus, deren entsprechende Kanäle für E / A-Vorgänge bereit sind. langes Argument ist eine Auszeit.
int select (java.util.function.Consumer) : wie oben, jedoch ohne Zeitüberschreitung.
int selectNow (java.util.function.Consumer) : wie oben, nur nicht blockierend.

java.nio.file.Files

String readString (Pfad) : Liest den gesamten Inhalt einer Datei in einen String und decodiert mithilfe der UTF-8-Codierung von Bytes in Zeichen.
String readString (Pfad, Zeichensatz) : Wie oben angegeben, mit dem Unterschied, dass die Dekodierung von Bytes zu Zeichen mit dem angegebenen Zeichensatz erfolgt.
Pfad writeString (Pfad, CharSequence, java.nio.file.OpenOption []) : Schreiben Sie CharSequence in eine Datei. Zeichen werden mithilfe der UTF-8-Codierung in Bytes codiert.
Pfad writeString (Pfad, CharSequence, java.nio.file.Charset, OpenOption []) : Wie oben werden Zeichen in Bytes mit der in Zeichensatz angegebenen Codierung codiert.

java.nio.file.Path

Pfad von (String, String []) : Gibt den Pfad aus dem String-Argument des Pfads oder der Folge von Strings zurück, die zusammen die Pfadzeichenfolge bilden.
Pfad von (net.URI) : Gibt den Pfad von der URI zurück.

java.util.Collection

Object [] toArray (java.util.function.IntFunction) : Gibt ein Array zurück, das alle Elemente in dieser Auflistung enthält. Verwenden Sie dazu die bereitgestellte Generierungsfunktion, um das zurückgegebene Array zuzuweisen.

java.util.concurrent.PriorityBlockingQueue

java.util.PriorityQueue

void forEach (java.util.function.Consumer) : Führt die übergebene Aktion für jedes Iterable-Element aus, bis alle Elemente verarbeitet wurden oder die Aktion eine Ausnahme auslöst.
boolean removeAll (java.util.Collection) : Entfernt alle Elemente dieser Sammlung, die auch in der angegebenen Sammlung enthalten sind (optionale Operation).
boolean removeIf (java.util.function.Predicate) : Entfernt alle Elemente aus dieser Sammlung, die das angegebene Prädikat erfüllen.
boolean keepAll (java.util.Collection) : Speichert nur die Elemente in dieser Sammlung, die in der übertragenen Sammlung enthalten sind (optionale Operation).

java.util.concurrent.TimeUnit

long convert (java.time.Duration) : konvertiert die übergebene Duration in diesen Typ.

java.util.function.Predicate

Prädikat nicht (Prädikat) : Gibt das Prädikat zurück, bei dem es sich um die Negation des übertragenen Prädikats handelt.

Dies ist eine meiner neuen Lieblings-APIs in JDK 11. Als Beispiel können Sie diesen Code konvertieren:

  lines.stream() .filter(s -> !s.isBlank())

  lines.stream() .filter(Predicate.not(String::isBlank))

oder wenn wir statische Importe verwenden:

  lines.stream() .filter(not(String::isBlank))

Persönlich glaube ich, dass diese Version verständlicher und prägnanter ist.

java.util.Optional

java.util.OptionalInt

java.util.OptionalDouble

java.util.OptionalLong

boolean isEmpty () : Wenn kein Wert vorhanden ist, wird true zurückgegeben, andernfalls false.

java.util.regex.Pattern

Prädikat asMatchPredicate () : Ich denke, es könnte das Juwel der neuen JDK 11-API sein. Erstellt ein Prädikat, das prüft, ob diese Vorlage mit der angegebenen Eingabezeichenfolge übereinstimmt.

java.util.zip.Deflater

int deflate (ByteBuffer) : Komprimiert die Eingabe und füllt den angegebenen Puffer damit.
int deflate (ByteBuffer, int) : Komprimiert die Eingabe und füllt den angegebenen Puffer damit. Gibt die tatsächliche Menge der komprimierten Daten zurück.
void setDictionary (ByteBuffer) : Legt das angegebene Wörterbuch für die Komprimierung auf Bytes in diesem Puffer fest. Dies ist eine überladene Form einer vorhandenen Methode, die ein ByteBuffer jetzt akzeptieren kann, anstatt eines Byte-Arrays.
void setInput (ByteBuffer) : Legt die zu komprimierende Eingabe fest. Auch eine überladene Form einer vorhandenen Methode.

java.util.zip.Inflater

int inflate (ByteBuffer) : Dekomprimiert Bytes in den angegebenen Puffer. Gibt die tatsächliche Anzahl entpackter Bytes zurück.
void setDictionary (ByteBuffer) : Setzt das angegebene Wörterbuch auf Bytes in diesem Puffer. Die überladene Form einer vorhandenen Methode.
void setInput (ByteBuffer) : Legt die Eingabe für die Dekomprimierung fest. Die überladene Form einer vorhandenen Methode.

javax.print.attribute.standard.DialogOwner

Dies ist eine neue Klasse in JDK 11. Wird verwendet, um eine Anforderung für einen Druckdialog oder eine Seiteneinrichtung zu unterstützen. Muss über allen Fenstern oder einem bestimmten Fenster angezeigt werden.

javax.swing.DefaultComboBoxModel

javax.swing.DefaultListModel

void addAll (Sammlung) : Fügt alle in der Sammlung vorhandenen Elemente hinzu.
void addAll (int, Collection) : Fügt alle in der Sammlung vorhandenen Elemente ab dem angegebenen Index hinzu.

javax.swing.ListSelectionModel

int [] getSelectedIndices () : Gibt ein Array aller ausgewählten Indizes im ausgewählten Modell in aufsteigender Reihenfolge zurück.
int getSelectedItemsCount () : Gibt die Anzahl der ausgewählten Elemente zurück.

jdk.jshell.EvalException

jshell.JShellException getCause () : Gibt einen auslösbaren Ursachen-Wrapper im Ausführungsclient zurück, der durch eine EvalException dargestellt wird, oder null, wenn die Ursache nicht vorhanden oder unbekannt ist.

Neue Funktionen (keine öffentliche API)

JEP 181: Nestbasierte Zugriffskontrolle

Java (und andere Sprachen) unterstützt verschachtelte Klassen durch innere Klassen. Für die korrekte Operation muss der Compiler einige Tricks ausführen. Zum Beispiel:

  public class Outer { private int outerInt; class Inner { public void printOuterInt() { System.out.println("Outer int = " + outerInt); } } }

Der Compiler ändert dies, um vor dem Kompilieren Folgendes zu erstellen:

  public class Outer { private int outerInt; public int access$000() { return outerInt; } }

  class Inner$Outer { Outer outer; public void printOuterInt() { System.out.println("Outer int = " + outer.access$000()); } }

Obwohl die innere Klasse logischerweise Teil desselben Codes wie die äußere Klasse ist, wird sie als separate Klasse kompiliert. Dies erfordert daher eine synthetische Methode ("Brücke"), die vom Compiler erstellt werden muss, um Zugriff auf das private Feld der externen Klasse zu erhalten.

Dieser JEP stellt das Konzept eines „Sockets“ dar, bei dem zwei Mitglieder desselben Sockets (außen und innen aus unserem Beispiel) Nachbarn sind. Im Dateiformat * .class wurden zwei neue Attribute hinzugefügt: NestHost und NestMembers. Diese Änderungen sind auch für andere mit Bytecode kompilierte Sprachen nützlich, die verschachtelte Klassen unterstützen.

Diese Funktion bietet drei neue Methoden für java.lang.Class:

Klasse getNestHost ()
Klasse [] getNestMembers ()
boolean isNestmateOf (clazz)

Diese Funktion erforderte auch Änderungen an der Java Virtual Machine Specification (JVMS) , insbesondere in Abschnitt 5.4.4 Zugriffssteuerung.

JEP 309: Dynamische Klassendateikonstanten

Dieser JEP beschreibt die Erweiterung des Dateiformats * .class, um das neue Formular mit dem konstanten Pool CONSTANT_Dynamic (in Präsentationen häufig als condy bezeichnet) zu unterstützen. Die Idee einer dynamischen Konstante scheint ein Oxymoron zu sein, aber tatsächlich kann man sie sich als endgültigen Wert in Java vorstellen. Der Wert des Konstantenpools wird nicht in der Kompilierungsphase festgelegt (im Gegensatz zu anderen Konstanten), aber die Bootstrap-Methode wird verwendet, um den Wert zur Laufzeit zu bestimmen. Daher ist der Wert dynamisch, aber da sein Wert nur einmal festgelegt wird, ist er auch konstant.

Diese Funktion ist vor allem für diejenigen nützlich, die neue Sprachen und Compiler entwickeln. Wer generiert den Bytecode und die * .class-Dateien, um sie auf der JVM auszuführen? Dies vereinfacht einige Aufgaben.

Diese Funktion bietet eine neue Klasse java.lang.invoke.ConstantBootstraps mit neun neuen Methoden. Ich werde sie hier nicht alle auflisten; Dies sind Bootstrap-Methoden für dynamisch berechnete Konstanten.

Diese Funktion erforderte Änderungen am JVMS, insbesondere hinsichtlich der Verwendung des speziellen Aufrufbytecodes und von Abschnitt 4.4 des Konstantenpools.

JEP 315: Verbessern Sie Aarch64 Intrinsics

Dies war der JEP von Red Hat. Die JVM kann jetzt speziellere Anweisungen verwenden, die im Befehlssatz von Arm 64 verfügbar sind. Dies verbessert insbesondere die Funktionsweise der Methoden sin (), cos () und log () der Klasse java.lang.Math.

JEP 318: Der Epsilon Garbage Collector

Red Hat hat ebenfalls zu diesem JEP beigetragen. Der Epsilon-Müllsammler ist etwas ungewöhnlich, da er keinen Müll sammelt! Bei der Erstellung neuer Objekte wird bei Bedarf neuer Speicher zugewiesen, der von Objekten ohne Verknüpfungen belegte Speicherplatz wird jedoch nicht freigegeben.

Es scheint also, worum geht es? Es gibt mindestens zwei Verwendungszwecke:

Zunächst soll dieser Kollektor sicherstellen, dass neue GC-Algorithmen hinsichtlich ihrer Auswirkungen auf die Leistung bewertet werden. Die Idee ist, eine Beispielanwendung mit Epsilon GC auszuführen und eine Metrik zu generieren. Ein neuer GC-Algorithmus ist enthalten, die gleichen Tests werden ausgeführt und die Ergebnisse werden verglichen.
Für sehr kurze oder kurzlebige Aufgaben (denken Sie an eine serverlose Funktion in der Cloud), bei der Sie sicherstellen können, dass Sie den dem Heap-Speicher zugewiesenen Speicher nicht überschreiten. Dies kann die Leistung verbessern, indem der Overhead (einschließlich der Erfassung von Statistiken, die zur Entscheidung über die Ausführung des Kollektors erforderlich sind) im Anwendungscode entfällt.

Wenn der Heap-Speicherplatz erschöpft ist, kann der nachfolgende JVM-Betrieb auf drei Arten konfiguriert werden:

Ein regulärer OutOfMemoryError wird aufgerufen.
Heap zurücksetzen
Es ist schwierig, die JVM anzuhalten und möglicherweise eine externe Aufgabe auszuführen (z. B. den Debugger zu starten).

JEP 324: Schlüsselvereinbarung mit Curve25519 und Curve448

Kryptografische Standards ändern sich ständig und verbessern sich. In diesem Fall wird das vorhandene Diffie-Hellman-Schema mit einer elliptischen Kurve durch Curve25519 und Curve448 ersetzt. Dies ist ein in RFC-7748 definiertes Schlüsselvereinbarungsschema.

JEP 327: Unicode 10

Die Java-Plattform unterstützt Unicode, um die Verarbeitung aller Zeichensätze zu ermöglichen. Da Unicode auf Version 10 aktualisiert wurde, wurde auch das JDK aktualisiert, um diese Version des Standards zu unterstützen.

Ich bin immer wieder gespannt, was Unicode-Entwickler in neuen Versionen enthalten. Unicode 10 hat 8.518 neue Zeichen. Dazu gehören das Bitcoin-Symbol, der Nüshu-Zeichensatz (von chinesischen Frauen zum Schreiben von Gedichten verwendet) sowie der Soyombo- und der Zanabazar-Platz (die Zeichen, die in historischen buddhistischen Texten zum Schreiben von Sanskrit-, tibetischen und mongolischen Sprachen verwendet werden). Viele andere Emoji wurden ebenfalls hinzugefügt, einschließlich des lang erwarteten (anscheinend) Colbert Emoji .

Denken Sie daran, dass Sie ab JDK 9 UTF-8 in Eigenschaftendateien (.properties) verwenden können. Dies bedeutet, dass in solchen Dateien jedes Unicode-Zeichen verwendet werden kann. Einschließlich Emojis. Nüshu.

JEP 328: Flight Recorder

Flight Recorder — JVM. JDK 11 Oracle JDK. , Oracle Oracle JDK OpenJDK, OpenJDK.

JEP :

API
, JVM HotSpot JDK

: jdk.jfr jdk.management.jfr.

JEP 329: ChaCha20 and Poly1305 Cryptographic Algorithms

JEP 324, , JDK. ChaCha20 ChaCha20-Poly1305, RFC 7539. ChaCha20 — , , RC4.

JEP 331: Low-overhead Heap Profiling

, JEP, Google. Java JVM.

,
( , GC VM)
Java.

JEP 332: Transport Layer Security (TLS) 1.3

TLS 1.3 (RFC 8446) " " TLS . JDK , Datagram Transport Layer Security (DTLS).

JEP 333: ZGC A Scalable, Low Latency Garbage Collector

, , () . ( , Weak Generational Hypothesis ) ( ) GC . "" , . .

ZGC — region-based ( G1), NUMA aware compacting . .

pauseless , C4 Zing JVM.

JEP 335: Deprecate the Nashorn Scripting Engine

Nashorn JDK 8 Rhino Javascript . , Nashorn API jjs Java. , . Graal VM , , .

JEP 336: Deprecate the Pack200 Tools and APIs

Pack200 — JAR-, Java SE 5.0. JPMS JDK 9 Pack200 JDK. pack200 unpack200 API Pack200 java.util.jar JDK. , .

Schlussfolgerungen

JDK 11 — LTS JDK ( ). , , , , JVM , .

Zulu JDK 11 !

JDK 11?

( . : , )

90 neue Funktionen (und APIs) in JDK 11