90 neue Funktionen (und APIs) in JDK 11

Ursprünglicher Autor: Simon Ritter
  • Übersetzung

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



Der neue sechsmonatige JDK-Veröffentlichungszyklus bedeutet für viele, dass einige noch nicht einmal herausgefunden haben, welche neuen Funktionen in JDK 10 und kurz vor JDK 11 verfügbar sind. In einem der frühen Blogs ( Englisch ) 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 für Entwickler verfügbar sind (öffentliche API), und alles andere. Wenn Sie nur daran interessiert sind, was Ihre Entwicklung direkt beeinflusst, können Sie den zweiten Teil überspringen.


Die Gesamtzahl der Veränderungen , die zählen konnten, gefunden wurde 90 zu sein (diesen JEP plus neue Klassen und Methoden, die Beseitigung verschiedene Methoden für HTTP-Client und Flight Recorder ) ( ca. Übersetzung :. Java Flight Recorder (JFR) war einer der kommerziellen Add-ons von Orakla gebaut im JDK, aber seit Java 11 dank JEP 328 auf Open Source übertragen) . Obwohl JDK 11 elf weniger Änderungen als JDK 10 feststellen konnte, ist es meiner Meinung nach zu Recht, dass JDK 11 mehr Funktionalität hinzugefügt wurde, einzig auf JVM-Ebene.


Neue auffällige Funktionen für den Entwickler


In JDK 11 gibt es einige Änderungen, die den Entwicklungsstil beeinflussen können. Es gibt eine geringfügige Syntaxänderung, viele neue APIs und die Möglichkeit, Anwendungen in einer Datei ohne Compiler auszuführen ( beachten Sie den Übersetzer: die sogenannten Shebang-Dateien ). Darüber hinaus besteht eine große (und entscheidende) Änderung darin, das Modul java.se.ee zu entfernen , was die Übertragung einer vorhandenen Anwendung auf das JDK 11 beeinträchtigen kann.


JEP 323: Local-Variable-Syntax für Lambda-Parameter


In JDK 10 wurde die Ausgabe lokaler Variablen (oder Typinferenz) eingeführt ( JEP 286 ). Dies vereinfacht den Code, da Sie den Typ einer lokalen Variablen nicht mehr explizit angeben müssen . Stattdessen können Sie var verwenden . Der JEP 323 erweitert die Verwendung dieser Syntax, die nun auch für die Parameter von Lambda-Ausdrücken gilt. Ein einfaches Beispiel:


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

Ein aufmerksamer Java-Programmierer weist darauf hin, dass Lambda-Ausdrücke bereits eine Typinferenz haben, sodass die Verwendung von var (in diesem Fall) überflüssig wäre. Wir könnten genauso einfach den gleichen Code schreiben wie:


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

Warum war es notwendig, Var-Unterstützung hinzuzufügen? Die Antwort ist ein Sonderfall - wenn Sie dem Lambda-Parameter eine Anmerkung hinzufügen möchten. Ohne die Teilnahme jeglicher Art ist es unmöglich. Um die Verwendung eines expliziten Typs zu vermeiden, können Sie var zur Vereinfachung verwenden.


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

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


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


JEP 330: Starten Sie Single-File-Quellcode-Programme


Eine der Kritikpunkte an Java ist die Redundanz der Syntax, und die „Zeremonie“, die mit dem Start einer trivialen Anwendung verbunden ist, kann die Eintrittsschwelle für Anfänger erheblich erhöhen. Um eine Anwendung zu schreiben, die einfach „Hallo Welt!“ Druckt, müssen Sie eine Klasse mit einer öffentlich verfügbaren statischen void-Hauptmethode schreiben und die System.out.println () -Methode verwenden. Danach müssen Sie den Code mit Javac kompilieren. Schließlich können Sie eine App ausführen, die die Welt begrüßt. Das Ausführen des gleichen Skripts in den meisten modernen Sprachen ist viel einfacher und schneller.


Mit JEP 330 muss keine Einzeldatei-Anwendung kompiliert werden. Nun geben Sie einfach ein:


            java HelloWorld.java

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


Nach dem Namen der Quelldatei hinterlegte Argumente werden beim Starten der Anwendung als Argumente übergeben. Argumente, die vor dem Namen der Quelldatei platziert werden, werden als Argumente an den Java-Launcher übergeben, nachdem der Code kompiliert wurde (damit können Sie beispielsweise den Klassenpfad in der Befehlszeile festlegen). Mit dem Compiler verknüpfte Argumente (z. B. der Pfad zu den Klassen) werden ebenfalls zum Kompilieren an javac übergeben.


Beispiel:


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

Es wird gleichbedeutend sein mit:


            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 den Java-Launcher in der Befehlszeile nicht einmal erwähnen zu müssen, können Sie ihn in die erste Zeile der Quelldatei aufnehmen. Zum Beispiel:


            #!/usr/bin/java --source 11publicclassHelloWorld{
            ...

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


JEP 321: HTTP-Client (Standard)


JDK 9 bietet eine neue API zur Unterstützung des HTTP-Client-Protokolls ( JEP 110 ). Da JDK 9 das Java Platform Module System (JPMS) zur Verfügung stellte , wurde diese API als Inkubator-Modul aufgenommen . Incubator-Module bieten neue APIs, machen sie jedoch nicht zu einem Java SE-Standard. Entwickler können die API mit Feedback testen. Nachdem Sie die erforderlichen Änderungen vorgenommen haben (diese API wurde in JDK 10 aktualisiert), kann die API zum Hauptmodul übertragen werden, um Teil des Standards zu werden.


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


  • Httpclient
  • Httprequest
  • HttpResponse
  • Websocket

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 konnte die monolithische Datei rt.jar in mehrere Module aufgeteilt werden. Ein weiterer Vorteil von JPMS ist, 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 explizit definierten Grenzen können veraltete Module nun einfacher von der Java-API entfernt werden. Dies ist, was diese JEP macht; Das Metamodul java.se.ee enthält sechs Module, die nicht mehr zum Java SE 11-Standard gehören und nicht im JDK enthalten sind.


Remote-Module:


  • corba ( ca. Übersetzer:ruhe in Friedenbrennen in der hölle )
  • Transaktion
  • Aktivierung
  • xml.bind
  • xml.ws
  • xml.ws.annotation

Diese Module wurden seit JDK 9 als obsolete (@Deprecated) markiert und nicht standardmäßig in die Kompilierung oder Laufzeitumgebung aufgenommen. Wenn Sie versucht haben, eine Anwendung zu kompilieren oder auszuführen, die die API aus diesen Modulen in JDK 9 oder JDK 10 verwendet, schlagen Sie fehl. Wenn Sie die API dieser Module in Ihrem Code verwenden, müssen Sie sie als separates Modul oder Bibliothek bereitstellen. Nach den Bewertungen zu urteilen, scheint es, dass die java.xml-Module, die Teil der Unterstützung für JAX-WS, SOAP-Webdienste sind, diejenigen sind, die die meisten Probleme verursachen.


Neue öffentliche API


Viele neue APIs in JDK 11 sind das Ergebnis der Tatsache, dass das HTTP-Client-Modul nun Teil des Standards ist, sowie die Aufnahme von Flight Recorder.


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


Hier sind alle neuen Methoden, die sich von denen unterscheiden, die in den Modulen java.net.http und jdk.jfr enthalten sind. Neue Methoden und Klassen werden auch nicht in den java.security-Modulen aufgelistet, die für Änderungen von JEP 324 und JEP 329 recht spezifisch sind (es gibt sechs neue Klassen und acht neue Methoden).


java.io.ByteArrayOutputStream


  • void writeBytes (Byte []) : schreibt alle Bytes aus dem Argument in den OutputStream

java.io.FileReader


Zwei neue Konstruktoren, mit denen Sie das Zeichensatz festlegen können.


java.io.FileWriter


Vier neue Konstruktoren, mit denen Sie das Zeichensatz festlegen können.


java.io.InputStream


  • io.InputStream nullInputStream () : Gibt einen InputStream zurück, der keine Bytes liest. Betrachtet man diese Methode (und die in OutputStream, Reader und Writer), stellt sich die Frage, warum sie nützlich sein kann. Sie können sich diese als / dev / null vorstellen - um nicht benötigte Ausgaben auszugeben oder Eingaben bereitzustellen, die immer null Byte 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 die überladene Form der vorhandenen Methode. Anstelle von char wird jedoch ein int verwendet. Int - Unicode-Codepunkt.

java.lang.CharSequence


  • int compare (CharSequence, CharSequence) : vergleicht zwei Instanzen von CharSequence lexikographisch . 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.Referenz


  • lang.Object clone () : Ich muss zugeben, diese Änderung führt zu Verwirrung. Die Reference-Klasse implementiert die Cloneable-Schnittstelle nicht und diese Methode löst eine CloneNotSupportedException-Ausnahme aus. Es muss einen Grund dafür geben, vielleicht für etwas in der Zukunft. ( Kommentar 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 zum JDK 11 kann ein Problem auftreten).


java.lang.String


Ich denke, das 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 einen Stream aus einer aus dieser Zeichenfolge extrahierten Zeichenfolge zurück, getrennt durch ein Zeichenfolge-Trennzeichen.
  • String repeat (int) : Gibt einen String zurück, dessen Wert die Verkettung dieses Strings ist, die mehrmals wiederholt wird.
  • String strip () : Gibt eine Zeichenfolge zurück, deren Wert diese Zeichenfolge ist. Dadurch werden alle Leerzeichen am Anfang und am Ende der Zeichenfolge entfernt.
  • String stripLeading () : Gibt eine Zeichenfolge zurück, deren Wert diese Zeichenfolge ist. Alle Leerzeichen am Anfang der Zeichenfolge werden entfernt.
  • String stripTrailing () : Gibt eine Zeichenfolge zurück, deren Wert diese Zeichenfolge ist, und alle Leerzeichen am Ende der Zeichenfolge werden gelöscht.

Wahrscheinlich schauen Sie sich strip () an und fragen: "Wie unterscheidet sich diese von der vorhandenen trim () - Methode ?" Die Antwort liegt in der unterschiedlichen Definition von Leerzeichen. ( Kommentar des Übersetzers: kurz gesagt, versteht strip () besser für Unicode, detaillierte Analyse von StackOverflow )


java.lang.StringBuffer


java.lang.StringBuilder


Beide Klassen verfügen über eine neue compareTo () - Methode , die einen StringBuffer / StringBuilder akzeptiert und ein 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 Kompatibilitätsproblemen führen.


java.nio.ByteBuffer


java.nio.CharBuffer


java.nio.DoubleBuffer


java.nio.FloatBuffer


java.nio.LongBuffer


java.nio.ShortBuffer


Alle diese Klassen verfügen jetzt über eine Mismatch () - Methode , die den relativen Index der ersten Nichtübereinstimmung zwischen diesem Puffer und dem übertragenen Puffer ermittelt und zurückgibt.


java.nio.channels.SelectionKey


  • int interestOpsAnd (int) : Setzt das Interesse des Schlüssels atomar auf den bitweisen Schnittpunkt ("und") der vorhandenen Interessengruppe und den übergebenen Wert.
  • int interestOpsOr (int) : Setzt das Interesse des Schlüssels atomar auf die bitweise Vereinigung ("oder") der vorhandenen Interessengruppe und den übergebenen Wert.

java.nio.channels.Selector


  • int select (java.util.function.Consumer, long) : Auswählen und Ausführen von Aktionen für die Tasten, deren entsprechende Kanäle für E / A-Operationen bereit sind. langes Argument ist ein Timeout.
  • int select (java.util.function.Consumer) : wie oben, jedoch ohne Timeout.
  • int selectNow (java.util.function.Consumer) : wie oben, nur nicht blockierend.

java.nio.file.files


  • String readString (Path) : Liest den gesamten Inhalt von der Datei in den String und dekodiert ihn von Bytes in Zeichen mit UTF-8-Codierung.
  • String readString (Path, Charset) : wie oben angegeben, mit dem Unterschied, dass die Dekodierung von Bytes in Zeichen mit dem angegebenen Charset erfolgt.
  • Pfad writeString (Pfad, CharSequence, java.nio.file.OpenOption []) : CharSequence in eine Datei schreiben. Zeichen werden mit der UTF-8-Kodierung in Byte kodiert.
  • Pfad writeString (Pfad, CharSequence, java.nio.file.Charset, OpenOption []) : Wie oben werden die Zeichen in Byte mit dem in Charset angegebenen Zeichensatz codiert.

java.nio.file.Path


  • Path of (String, String []) : Gibt einen Pfad von einem String-Argument zu einem Pfad oder einer Folge von Strings zurück, die zusammen einen String-Pfad bilden.
  • Pfad von (net.URI) : Gibt einen Pfad von einem 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, wobei das zurückgegebene Array mithilfe der bereitgestellten Generierungsfunktion zugewiesen wird.

java.util.concurrent.PriorityBlockingQueue


java.util.PriorityQueue


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

java.util.concurrent.TimeUnit


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

java.util.function.Predicate


  • Prädikat nicht (Prädikat) : Gibt ein Prädikat zurück, das die Negation des übergebenen Prädikats ist.

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


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

in der


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

oder wenn wir statischen Import verwenden:


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

Ich persönlich finde diese Version verständlicher und prägnanter.


java.util.Optional


java.util.OptionalInt


java.util.OptionalDouble


java.util.OptionalLong


  • boolean isEmpty () : Gibt true zurück, falls nicht vorhanden, andernfalls false.

java.util.regex.Pattern


  • Predicate asMatchPredicate () : Ich denke, es könnte die Perle der neuen JDK API 11 sein. Es erstellt ein Prädikat, das prüft, ob dieses Muster mit der angegebenen Eingabezeichenfolge übereinstimmt.

java.util.zip.Deflater


  • int deflate (ByteBuffer) : komprimiert die Eingabe und füllt den angegebenen Puffer.


  • int deflate (ByteBuffer, int) : komprimiert die Eingabe und füllt den angegebenen Puffer. Gibt die tatsächliche Menge der komprimierten Daten zurück.


  • void setDictionary (ByteBuffer) : Legt fest, dass das angegebene Wörterbuch in Byte in diesem Puffer komprimiert wird. Dies ist eine überladene Form einer vorhandenen Methode, die jetzt ein ByteBuffer anstelle eines Byte-Arrays akzeptieren kann.


  • void setInput (ByteBuffer) : Legt die Eingabe für die Komprimierung fest. Auch die überladene Form der vorhandenen Methode.



java.util.zip.Inflater


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

javax.print.attribute.standard.DialogOwner


Dies ist eine neue Klasse in JDK 11. Wird zur Unterstützung von Druckdialoganfragen oder Seiteneinstellungen verwendet. Muss über allen Fenstern oder einem bestimmten Fenster angezeigt werden.


javax.swing.DefaultComboBoxModel


javax.swing.DefaultListModel


  • void addAll (Collection) : fügt alle in der Collection vorhandenen Elemente hinzu.
  • void addAll (int, Collection) : fügt ab dem angegebenen Index alle Elemente der Collection 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 ausgeführten Client zurück, der durch EvalException dargestellt wird, oder null, wenn die Ursache nicht existiert oder unbekannt ist.

Neue Funktionen (nicht öffentliche API)


JEP 181: Nestbasierte Zugriffssteuerung


Java (und andere Sprachen) unterstützt verschachtelte Klassen durch innere Klassen. Für den ordnungsgemäßen Betrieb muss der Compiler einige Tricks ausführen. Zum Beispiel:


publicclassOuter{
    privateint outerInt;
     classInner{
       publicvoidprintOuterInt(){
         System.out.println("Outer int = " + outerInt);
       }
     }
   }

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


publicclassOuter{
      privateint outerInt;
      publicint access$000() {
        return outerInt; 
      }
    }

classInner$Outer{
      Outer outer;
      publicvoidprintOuterInt(){
        System.out.println("Outer int = " + outer.access$000());
      }
    }

Obwohl die innere Klasse logischerweise Teil des gleichen Codes wie die äußere Klasse ist, wird sie als separate Klasse kompiliert. Daher ist eine synthetische Methode ("bridge") erforderlich, die vom Compiler erstellt werden muss, um Zugriff auf das private Feld der äußeren Klasse zu erhalten.


Dieses JEP repräsentiert das Konzept des "Nestes", bei dem zwei Mitglieder desselben Nestes (in unserem Beispiel "Äußeres" und "Inneres") Nachbarn sind. Zum * .class-Dateiformat wurden zwei neue Attribute hinzugefügt: NestHost und NestMembers. Diese Änderungen sind auch für andere bytecode-kompilierte Sprachen hilfreich, die verschachtelte Klassen unterstützen.


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


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

Dieses Feature machte auch Änderungen an der Java Virtual Machine Specification (JVMS) erforderlich , insbesondere in Abschnitt 5.4.4 „Zugriffskontrolle“.


JEP 309: Dynamische Klassen-Dateikonstanten


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


Diese Funktion ist vor allem für diejenigen hilfreich, die neue Sprachen und Compiler entwickeln. Wer generiert die Bytecode- und * .class-Dateien für die Ausführung in der JVM? Dies vereinfacht einige Aufgaben.


Diese Funktion stellt eine neue Klasse java.lang.invoke.ConstantBootstraps mit neun neuen Methoden bereit. Ich werde sie hier nicht alle aufführen. Dies sind Methoden für das erstmalige Laden dynamisch berechneter Konstanten.


Diese Funktion erforderte Änderungen an der JVMS, insbesondere die Art und Weise, in der der Bytecode des speziellen Aufrufs und der Abschnitt 4.4 „The Constant Pool“ verwendet werden.


JEP 315: Verbesserung von Aarch64 Intrinsics


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


JEP 318: Der Epsilon-Müllsammler


Red Hat trug ebenfalls zu diesem JEP bei. Der Epsilon-Müllsammler ist etwas ungewöhnlich, da er keinen Müll sammelt! Es reserviert neuen Speicher, wenn es zum Erstellen neuer Objekte benötigt wird, gibt jedoch nicht den Speicherplatz frei, der von Objekten ohne Referenzen belegt wird.


Es scheint, was ist der Sinn? Es gibt mindestens zwei Verwendungen:


  • Zunächst ist dieser Collector so konzipiert, dass die neuen 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. Der neue GC-Algorithmus wird aktiviert, die gleichen Tests werden ausgeführt und die Ergebnisse werden verglichen.
  • Für sehr kurze oder kurzlebige Aufgaben (denken Sie an serverlose Funktionen in der Cloud), bei denen Sie garantieren können, dass Sie den dem Heap-Speicher zugewiesenen Speicher nicht überschreiten. Dies kann die Leistung verbessern, da keine zusätzlichen Kosten anfallen (einschließlich des Sammelns der Statistiken, die erforderlich sind, um eine Entscheidung über die Ausführung des Kollektors zu treffen) im Anwendungscode.

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


  • Normaler OutOfMemoryError aufgerufen.
  • Heap-Reset durchführen
  • Stoppen Sie die JVM und beenden Sie möglicherweise eine externe Aufgabe (z. B. Starten eines Debuggers).

JEP 324: Wichtige Vereinbarung mit Curve25519 und Curve448


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


JEP 327: Unicode 10


Die Java-Plattform unterstützt Unicode, um sicherzustellen, dass alle Zeichensätze verarbeitet werden. Seit der Aktualisierung von Unicode auf Version 10 wurde auch das JDK aktualisiert, um diese Version des Standards zu unterstützen.


Ich bin immer wieder gespannt, was Unicode-Entwickler in neueren Versionen enthalten. Unicode 10 enthält 8.518 neue Zeichen. Dazu gehören das Bitcoi-Symbol, der Nüshu-Zeichensatz (von chinesischen Frauen zum Schreiben von Gedichten verwendet) und Soyombo und Zanabazar Square (sind Symbole, die in historischen buddhistischen Texten zum Schreiben von Sanskrit, Tibetisch und Mongolisch verwendet werden). Es gibt auch viele andere Emoji, darunter den (scheinbar) lang erwarteten Colbert Emoji .


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


JEP 328: Flugschreiber


Flight Recorder ist eine einfache Datenerfassungsstruktur für die JVM. Vor JDK 11 war dies eine kommerzielle Funktion in einer kompletten Oracle JDK-Suite. Nachdem Oracle die funktionalen Unterschiede zwischen Oracle JDK und OpenJDK beseitigt hat, wurde dieses Feature in OpenJDK aufgenommen.


JEP identifiziert vier grundlegende Eigenschaften:


  • Bereitstellung einer API zum Schreiben und Lesen von Daten als Ereignisse
  • Stellen Sie einen Puffermechanismus und ein binäres Datenformat bereit

  • Konfiguration und Filterung von Ereignissen zulassen

  • Stellen Sie Ereignisse für BS-, JVM-HotSpot- und JDK-Bibliotheken bereit

Dafür gibt es zwei neue Module: jdk.jfr und jdk.management.jfr.


JEP 329: ChaCha20 und Poly1305 kryptographische Algorithmen


Wie bei JEP 324 ist dies ein Update der vom JDK verwendeten Chiffren. Implementieren Sie die Verschlüsselungscodes ChaCha20 und ChaCha20-Poly1305, wie in RFC 7539 angegeben. ChaCha20 ist eine relativ neue Stream-Verschlüsselung, die die alte, unsichere RC4-Stream-Verschlüsselung ersetzen kann.


JEP 331: Low-Overhead-Heap-Profiling


Es ist ein wenig überraschend, dass dies JEP ist, das von Google eingeführt wurde. Auf diese Weise können Sie Informationen zur Verteilung von Java-Objekten in der JVM erhalten.


Hauptmerkmale:


  • Geringe Arbeitslast, um fortlaufend standardmäßig aktiviert zu werden
  • Verfügbar über eine klar definierte Softwareschnittstelle.
  • Darf alle Distributionen anzeigen
  • Kann auf implementierungsunabhängige Weise definiert werden (d. H. Nicht auf einen bestimmten GC-Algorithmus oder eine VM-Implementierung beschränkt)

  • Kann Informationen über Java Live und Dead Objects bereitstellen.

JEP 332: Transport Layer Security (TLS) 1.3


TLS 1.3 (RFC 8446) ist die "Überholung" des TLS-Protokolls und bietet gegenüber früheren Versionen eine deutliche Steigerung der Sicherheit und Leistung. Das JDK unterstützt dies nun, obwohl es nicht für Datagram Transport Layer Security (DTLS) gilt.


JEP 333: ZGC Ein skalierbarer Garbage Collector mit niedriger Latenz


Dies ist ein neuer experimenteller Garbage Collector, der für Anwendungen entwickelt wurde, die einen großen Heap (mehrere Gigabyte) und geringe Latenz erfordern. Es verwendet eine Reihe von Generationen (was angesichts des allgemein akzeptierten Musters der Verwendung von Weak Generational Hypothesis ein wenig ungewöhnlich ist ) und führt die meisten (aber nicht alle) GC-Arbeiten gleichzeitig mit der Anwendung durch. Dies geschieht mit dem "Barriere" -Mechanismus für das Lesen, der jedes Lesen eines Objekts aus der Anwendung abfängt und sicherstellt, dass die Rückverbindung korrekt ist. Dadurch entfällt das Problem der gleichzeitigen Bewegung von Objekten während des Anwendungsflusses.


ZGC ist ein auf Regionen basierender (wie G1), NUMA-fähiger und verdichtender Müllsammler. Nicht als Allzweck-Sammler gedacht.


Wenn Sie wirklich einen pausenlosen Müllsammler mit geringer Latenz wollen, kann ich den C4 in unserer Zing JVM uneingeschränkt empfehlen.


JEP 335: Die Nashorn Scripting Engine sollte nicht mehr verwendet werden


Nashorn wurde in JDK 8 als effizienter Ersatz für die Rhino-Javascript-Engine eingeführt. Das Ziel ist, Nashorn zusammen mit dem API- und JJS-Tool aus einer zukünftigen Java-Version zu entfernen. Wann dies geschieht, ist noch nicht entschieden. Die Möglichkeit, Graal VM als Ersatz zu verwenden, wurde vorgeschlagen, aber wie es funktioniert, ist noch unklar.


JEP 336: Veraltet die Pack200-Tools und APIs


Pack200 ist ein Komprimierungsschema für JAR-Dateien, das seit Java SE 5.0 verwendet wird. Mit der Einführung von JPMS in JDK 9 wird das Pack200 nicht mehr zum Komprimieren des JDK selbst verwendet. Die Tools "pack200" und "unpack200" und "API Pack200" in java.util.jar sind nun veraltet und können in einer zukünftigen Version des JDK entfernt werden. Wenn dies passiert, nicht angegeben.


Schlussfolgerungen


JDK 11 ist die nächste Version des LTS-JDK (dies ist Orakl gefolgt von allen anderen). Obwohl es nicht so viele entwicklerorientierte Funktionen gibt, hat sich in der JVM vieles geändert, doch sie schafft die Grundlage für zukünftige, wichtigere Funktionen.


Zulu build JDK 11 kann hier gefunden werden und ist absolut kostenlos!


Ist es an der Zeit, Ihre Anwendungen auf JDK 11 zu migrieren?


( Hinweis des Übersetzers: Anfrage, alle Übersetzungsfehler und andere Ungenauigkeiten, die an das LAN gesendet werden )


Jetzt auch beliebt: