Cloud-Lösungen der Zukunft - Testen!

Revolutionäre Cloud-Technologie, ganz ohne versteckte Kosten. Profitieren Sie von unserer Testphase und entdecken Sie umfassende Funktionen. Der Anmeldeprozess ist transparent und unkompliziert. Starten Sie jetzt Ihre Reise in die Cloud - Kostenfrei!

Java 10 Features – Überblick

Java 10 ist die schnellste Veröffentlichung einer Java-Version in ihrer 23-jährigen Geschichte. Java wurde wegen seines langsamen Wachstums und seiner Entwicklung kritisiert, aber Java 10 hat dieses Konzept zerschlagen. Java 10 ist eine Veröffentlichung mit vielen zukunftsweisenden Änderungen, deren Umfang und Auswirkungen vielleicht nicht offensichtlich sind, aber weitreichend. In diesem Artikel werden wir die verschiedenen in Java 10 hinzugefügten Features diskutieren. Zuvor gehen wir jedoch auf einige Änderungen im Java-Veröffentlichungsmodell ein.

Long Term Support Model – Java 10 Features

Ab 2017 kündigten Oracle & die Java-Community ihren Wechsel zu einem neuen 6-Monats-Rhythmus für Java an. Es wechselte zu einem Long Term Support (LTS)-Modell für Oracle Java SE-Produkte. Was bedeutet das? Die LTS-Version der Produkte wird erstklassige und anhaltende Unterstützung von Oracle bieten und alle drei Jahre angepeilt. Jede Java-Veröffentlichung ist nach ein oder zwei Hauptfeatures modelliert, diese Features treiben die Veröffentlichung an. Jedes Hindernis verzögert die Veröffentlichung und kommt spät auf den Markt. Project Jigsaw war ein Hauptfeature von Java 9, es verschob die Veröffentlichungstermine ein paar Mal und die Veröffentlichung verzögerte sich um mehr als 1,5 Jahre. Der 6-Monats-Rhythmus wird einem Veröffentlichungszug folgen. Der Veröffentlichungszug hat alle 6 Monate einen Fahrplan. Features, die den Schnitt machen, steigen in den Zug ein; andernfalls warten sie auf den nächsten geplanten Zug.

Oracle JDK vs. Open JDK

Um benutzerfreundlicher zu sein, fördert Oracle & die Java-Community nun die OpenJDK-Binärdateien als primäres JDK für die Zukunft. Dies ist eine große Erleichterung gegenüber früheren Tagen, als die JDK-Binärdateien proprietär waren und von Oracle lizenziert wurden, was verschiedene Einschränkungen bei der Weiterverteilung mit sich brachte. Oracle wird jedoch weiterhin ihr JDK produzieren, aber nur für Long-Term-Support-Releases. Dies ist ein Schritt hin zu mehr Cloud- & Containerfreundlichkeit, da die OpenJDK-Binärdateien als Teil eines Containers verteilt werden können. Was bedeutet das? Open JDK-Binärdateien werden alle 6 Monate veröffentlicht, während Oracle JDK-Binärdateien alle 3 Jahre (LTS-Version) veröffentlicht werden. Welche JDK-Binärdateien werden übernommen? Große Organisationen brauchen Zeit, um zwischen den Versionen zu wechseln; sie halten an der Version fest, bis sie können. Die Industrieadoption für Java 6 war größer als für Java 7 und dann bewegt sich die Industrie allmählich zu Java 8. Meiner Meinung nach wird die LTS-Version von den Unternehmen am meisten bevorzugt. Ob es jedoch die LTS-Version von Oracle JDK oder das Open JDK sein wird, ist noch nicht bekannt, teilweise weil viel im Cloud-Bereich passiert. Java 9 & 10 sind keine LTS-Releases. Java 11, das im September 2018 erscheinen soll, wird ein LTS-Release sein.

Java 10 Features

Zeitbasierte Versionsnummerierung (JEP 322)

Mit der Übernahme des zeitbasierten Veröffentlichungszyklus hat Oracle das Schema der Versionsnummerierung der Java SE-Plattform und des JDK sowie die damit verbundenen Versionsinformationen für gegenwärtige und zukünftige zeitbasierte Veröffentlichungsmodelle geändert. Das neue Muster der Versionsnummer ist: $FEATURE.$INTERIM.$UPDATE.$PATCH $FEATURE: Der Zähler wird alle 6 Monate erhöht und basiert auf Feature-Release-Versionen, z. B.: JDK 10, JDK 11. $INTERIM: Der Zähler wird für Non-Feature-Releases erhöht, die kompatible Bugfixes und Verbesserungen enthalten, aber keine inkompatiblen Änderungen. Üblicherweise wird dies Null sein, da es in einem Sechs-Monats-Zeitraum keine Zwischenveröffentlichung geben wird. Dies bleibt für eine zukünftige Überarbeitung des Veröffentlichungsmodells erhalten. $UPDATE: Der Zähler wird für kompatible Update-Releases erhöht, die Sicherheitsprobleme, Regressionen und Bugs in neueren Features beheben. Dies wird einen Monat nach der Feature-Veröffentlichung und danach alle 3 Monate aktualisiert. Die Veröffentlichung im April 2018 ist JDK 10.0.1, die Veröffentlichung im Juli ist JDK 10.0.2 und so weiter $PATCH: Der Zähler wird für einen Notfall-Release zur Behebung eines kritischen Problems erhöht. Neue APIs wurden hinzugefügt, um diese Zählerwerte programmgesteuert zu erhalten. Werfen wir einen Blick darauf;

Version version = Runtime.version();
version.feature();
version.interim();
version.update();
version.patch();

Nun werfen wir einen Blick auf den Java-Launcher, der die Versionsinformationen zurückgibt:

$ java -version
java version "10" 2018-03-20
Java(TM) SE Runtime Environment 18.3 (build 10+46)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10+46, mixed mode)

Das Format der Versionsnummer ist „10“, da kein anderer Zähler außer Null vorhanden ist. Das Veröffentlichungsdatum ist hinzugefügt. 18.3 kann als das Jahr 2018 & der 3. Monat gelesen werden, Build 10+46 ist der 46. Build für Version 10. Für einen hypothetischen Build 93 von JDK 10.0.1 würde der Build 10.0.1+939 sein.

Lokale Variablen-Typinferenz (JEP 286)

Lokale Variablen-Typinferenz ist das größte neue Feature in Java 10 für Entwickler. Es fügt Typinferenz zu Deklarationen lokaler Variablen mit Initialisierern hinzu. Lokale Typinferenz kann nur in den folgenden Szenarien verwendet werden:

  • Beschränkt nur auf lokale Variablen mit Initialisierer
  • Indizes der erweiterten for-Schleife oder Indizes
  • Lokal in einer for-Schleife deklariert

Lassen Sie uns einen Blick auf die Verwendung werfen:

var numbers = List.of(1, 2, 3, 4, 5); // inferred value ArrayList
// Index of Enhanced For Loop
for (var number : numbers) {
    System.out.println(number);
}
// Local variable declared in a loop
for (var i = 0; i < numbers.size(); i++) {
    System.out.println(numbers.get(i));
}

Dieses Feature ermöglicht es, den auf Java basierenden JIT-Compiler, Graal, als experimentellen JIT-Compiler auf der Linux/x64-Plattform zu verwenden. Dies ist bei weitem die futuristischste Aufnahme in die Feature-Liste von Java 10. Graal wurde in Java 9 eingeführt. Es ist eine Alternative zu dem JIT-Compiler, den wir gewohnt waren. Es ist ein Plugin für die JVM, was bedeutet, dass der JIT-Compiler nicht an die JVM gebunden ist und dynamisch eingesteckt und durch ein anderes Plugin ersetzt werden kann, das JVMCI-konform ist (Java-Level JVM Compiler Interface). Es bringt auch Ahead of Time (AOT)-Kompilierung in die Java-Welt. Es unterstützt auch mehrsprachige Sprachinterpretation. „Ein auf Java basierender Just in Time Compiler, geschrieben in Java, um den Java-Bytecode in Maschinencode umzuwandeln.“ Ist das verwirrend? Wenn die JVM in Java geschrieben ist, benötigen Sie dann nicht eine JVM, um die JVM auszuführen? Die JVM kann AOT kompiliert werden und dann kann der JIT-Compiler innerhalb der JVM verwendet werden, um die Leistung durch Live-Code-Optimierung zu verbessern. Graal ist eine komplette Neuschreibung des JIT-Compilers in Java von Grund auf. Der vorherige JIT-Compiler wurde in C++ geschrieben. Es wird als eine der letzten Stufen der Evolution für jede Programmiersprache angesehen. Sie können zu Graal mit den folgenden JVM-Parametern wechseln:

-XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler

Dieses Feature hilft, den Startup-Fußabdruck zu verbessern, erweitert das bestehende Class-Data Sharing („CDS“)-Feature, um Anwendungsklassen im gemeinsamen Archiv zu platzieren. Die JVM führt beim Start einige vorläufige Schritte aus, einer davon ist das Laden von Klassen im Speicher. Wenn es mehrere Jars mit mehreren Klassen gibt, dann ist die Verzögerung bei der ersten Anfrage deutlich sichtbar. Dies wird zu einem Problem bei serverloser Architektur, wo die Boot-Zeit kritisch ist. Um die Anwendungsstartzeit zu verkürzen, kann das Application Class-data-Sharing verwendet werden. Die Idee ist, den Fußabdruck zu reduzieren, indem gemeinsame Klassenmetadaten über verschiedene Java-Prozesse hinweg geteilt werden. Dies kann durch die folgenden drei Schritte erreicht werden: Bestimmung der zu archivierenden Klassen: Verwenden Sie den Java-Launcher, um eine Liste von Dateien zu erstellen, die archiviert werden sollen. Dies kann durch die folgenden Parameter erreicht werden:

$java -Xshare:off -XX:+UseAppCDS -XX:DumpLoadedClassList=hello.lst -cp hello.jar HelloWorld

Erstellen des AppCDS-Archivs: Verwenden Sie den Java-Launcher, um das Archiv der Liste von Dateien zu erstellen, die für Application CDS verwendet werden sollen. Dies kann durch die folgenden Parameter erreicht werden:

$java -Xshare:dump -XX:+UseAppCDS -XX:SharedClassListFile=hello.lst -XX:SharedArchiveFile=hello.jsa -cp hello.jar

Verwenden des AppCDS-Archivs: Verwenden Sie den Java-Launcher mit den folgenden Parametern, um Application CDS zu verwenden.

$java -Xshare:on -XX:+UseAppCDS -XX:SharedArchiveFile=hello.jsa -cp hello.jar HelloWorld

Parallel Full GC for G1 (JEP 307)

Der G1-Müllsammler wurde standardmäßig in JDK 9 eingestellt. Der G1-Müllsammler vermeidet jede vollständige Müllsammlung, aber wenn parallele Sammelthreads den Speicher nicht schnell genug wiederbeleben können, wird das Benutzererlebnis beeinträchtigt. Diese Änderung verbessert die Worst-Case-Latenz von G1, indem die vollständige GC parallelisiert wird. Der Mark-Sweep-Compact-Algorithmus des G1-Sammlers wird als Teil dieser Änderung parallelisiert und wird ausgelöst, wenn parallele Sammelthreads den Speicher nicht schnell genug wiederbeleben können.

Garbage-Collector-Schnittstelle (JEP 304)

Dieses JEP ist eine futuristische Änderung. Es verbessert die Code-Isolation verschiedener Müllsammler durch Einführung einer gemeinsamen Garbage-Collector-Schnittstelle. Diese Änderung bietet eine bessere Modularität für den internen GC-Code. Dies wird in Zukunft beim Hinzufügen neuer GC ohne Änderung der bestehenden Codebasis helfen und auch bei der Entfernung oder Hausverwaltung des vorherigen GC helfen.

Zusätzliche Unicode-Sprach-Tag-Erweiterungen (JEP 314)

Diese Funktion verbessert java.util.Locale und verwandte APIs, um zusätzliche Unicode-Erweiterungen von BCP 47-Sprach-Tags zu implementieren. Ab Java SE 9 werden die unterstützten BCP 47 U-Sprach-Tag-Erweiterungen „ca“ und „nu“ unterstützt. Dieses JEP wird die Unterstützung für die folgenden zusätzlichen Erweiterungen hinzufügen:

  • cu (Währungstyp)
  • fw (erster Wochentag)
  • rg (Regionsüberschreibung)
  • tz (Zeitzone)

Um diese zusätzlichen Erweiterungen zu unterstützen, werden Änderungen an verschiedenen APIs vorgenommen, um Informationen basierend auf U oder zusätzlichen Erweiterungen bereitzustellen.

Root-Zertifikate (JEP 319)

Um OpenJDK zu fördern und es für Community-Nutzer attraktiver zu machen, bietet dieses Feature einen Standard-Satz von Root-Zertifizierungsstellen (CA)-Zertifikaten im JDK. Das bedeutet auch, dass sowohl Oracle- als auch OpenJDK-Binärdateien funktional gleich sein werden. Kritische Sicherheitskomponenten wie TLS funktionieren standardmäßig in OpenJDK-Builds.

Thread-Local Handshakes (JEP 312)

Dies ist ein internes JVM-Feature zur Leistungsverbesserung. Eine Handshake-Operation ist ein Callback, der für jeden JavaThread ausgeführt wird, während sich dieser Thread in einem Safepoint-Zustand befindet. Der Callback wird entweder vom Thread selbst oder vom VM-Thread ausgeführt, während der Thread in einem blockierten Zustand gehalten wird. Dieses Feature bietet eine Möglichkeit, einen Callback auf Threads auszuführen, ohne einen globalen VM-Safepoint durchzuführen. Es macht es sowohl möglich als auch kostengünstig, einzelne Threads anzuhalten und nicht nur alle Threads oder keinen.

Heap-Zuweisung auf alternativen Speichergeräten (JEP 316)

Anwendungen sind speicherhungrig geworden, es gibt einen Anstieg von cloud-nativen Anwendungen, In-Memory-Datenbanken, Streaming-Anwendungen. Um diesen Diensten gerecht zu werden, gibt es verschiedene Speicherarchitekturen. Diese Funktion verbessert die Fähigkeit der HotSpot VM, den Java-Objektheap auf einem alternativen Speichergerät, wie einem NV-DIMM, das vom Benutzer angegeben wird, zuzuweisen. Dieses JEP zielt auf alternative Speichergeräte ab, die die gleichen Semantiken wie DRAM haben, einschließlich der Semantik von atomaren Operationen, und daher anstelle von DRAM für den Objektheap verwendet werden können, ohne dass eine Änderung des bestehenden Anwendungscodes erforderlich ist.

Entfernung des Tools zur Native-Header-Generierung – javah (JEP 313)

Dies ist eine Hausmeisteränderung, um das javah-Tool aus dem JDK zu entfernen. Die Funktionalität des Tools wurde in javac als Teil von JDK 8 hinzugefügt, was die Möglichkeit bietet, native Headerdateien zur Kompilierzeit zu schreiben, was javah überflüssig macht.

Konsolidierung des JDK-Waldes in ein einziges Repository (JEP 296)

Im Laufe der Jahre gab es verschiedene Mercurial-Repositories für die JDK-Codebasis. Verschiedene Repositories bieten einige Vorteile, hatten aber auch verschiedene betriebliche Nachteile. Als Teil dieser Änderung werden zahlreiche Repositories des JDK-Waldes in ein einzelnes Repository zusammengeführt, um die Entwicklung zu vereinfachen und zu rationalisieren.

API-Änderungen – Java 10 Features

Java 10 hat APIs hinzugefügt und entfernt (Ja, es ist kein Tippfehler). Java 9 führte eine verbesserte Abschreibung ein, bei der bestimmte APIs zur Entfernung in zukünftigen Releases markiert wurden. Entfernte APIs: Hier finden Sie die entfernten APIs. Hinzugefügte APIs: In Java 10 wurden 73 neue APIs hinzugefügt. Hier finden Sie die hinzugefügten APIs zusammen mit einem Vergleich. Lassen Sie uns einige Neuzugänge durchgehen:

  • List-, Map- und Set-Schnittstellen wurden mit einer statischen copyOf(Collection)-Methode hinzugefügt. Sie gibt eine unveränderliche Liste, Karte oder ein Set mit den bereitgestellten Einträgen zurück. Für eine Liste, wenn die gegebene Liste anschließend modifiziert wird, wird die zurückgegebene Liste diese Modifikationen nicht widerspiegeln.
  • Optional und seine primitiven Variationen erhalten eine Methode orElseThrow(). Dies ist genau dasselbe wie get(), jedoch gibt das Java-Dokument an, dass es eine bevorzugte Alternative zu get() ist
  • Die Collectors-Klasse erhält verschiedene Methoden zum Sammeln unveränderlicher Sammlungen (Set, Liste, Karte)

List actors = new ArrayList<>();
actors.add("Jack Nicholson");
actors.add("Marlon Brando");
System.out.println(actors); // prints [Jack Nicholson, Marlon Brando]
// New API added - Creates an UnModifiable List from a List.
List copyOfActors = List.copyOf(actors);
System.out.println(copyOfActors); // prints [Jack Nicholson, Marlon Brando]
// copyOfActors.add("Robert De Niro"); Will generate an
// UnsupportedOperationException
actors.add("Robert De Niro");
System.out.println(actors); // prints [Jack Nicholson, Marlon Brando, Robert De Niro]
System.out.println(copyOfActors); // prints [Jack Nicholson, Marlon Brando]

String str = "";
Optional name = Optional.ofNullable(str);
// New API added - is preferred option then get() method
name.orElseThrow(); // same as name.get()  

// New API added - Collectors.toUnmodifiableList
List collect = actors.stream().collect(Collectors.toUnmodifiableList());
// collect.add("Tom Hanks"); // Will generate an
// UnsupportedOperationException

Schlussfolgerung – Java 10 Features

In diesem Artikel haben wir die verschiedenen Neuerungen der Java 10-Funktionen durchgegangen. Überblick

Start Your Cloud Journey Today with Our Free Trial!

Dive into the world of cloud computing with our exclusive free trial offer. Experience the power, flexibility, and scalability of our cloud solutions firsthand.

Try for free!