Was ist neu in Java 17?

Die Long-Term-Support (LTS)-Version der Java-Sprach- und Laufzeitplattform Java 17 wurde am 14. September 2021 eingeführt. Lassen Sie uns erfahren, was es Neues in Java 17 gibt und ob Sie ein Upgrade durchführen sollten.

Viele Anwendungen verwenden ältere Java-Versionen, einschließlich der früheren LTS-Versionen von Java: Java 11 und Java 8.

Warum sollten Unternehmen auf die aktuellste Java-Version upgraden? Das Upgrade auf Java 17 erfordert Anstrengung, hauptsächlich um die neuen Features und Funktionen innerhalb der JVM optimal zu nutzen.

Viele Unternehmen verwenden Docker und Docker-Bilder mit minimalem Aufwand und Zeitaufwand einfach auf Java 17 umzusteigen. Entwickler können ihre Continuous Integration/Deployment (CI/CD)-Pipelines definieren und alles in Docker-Images ausführen. Dies hat keine Auswirkungen auf andere Teams, die ältere Java-Versionen verwenden, da sie alte Docker-Images verwenden können.

JAVA 17-Funktionen

macOS- und AArch64-Unterstützung

Eine der kritischen JVM-Funktionen, die dieser Version hinzugefügt wurden, ist die Verbesserung der Unterstützung für macOS auf der AArch64-Architektur mit JEP 391. Es wird die neueste Reihe von Prozessoren (M1) unterstützen, die Apple im letzten Jahr mit seinen Computern veröffentlicht hat.

Für Benutzer dieser Plattformen ist dies nicht unbedingt eine große Sache, da einige Anbieter JDK-Versionen auf den Markt gebracht haben, die diese Architektur unterstützen und sogar Unterstützung von Java 8 zurückgeben. Das offizielle Gütesiegel ist jedoch unerlässlich, um die zukünftige Wartung und Unterstützung von die Platform. Im Vergleich dazu wurde die Unterstützung für die Linux/AArch64-Plattform zu Java 9 und Windows/AArch64 in Java 16 hinzugefügt.

Versiegelte Klassen

Sealed Classes is a feature that was introduced in Java 17. The sealed Classes feature has finished its trial phase and has become an official platform and language in Java 17. It permits a developer to specify the permissible sub-types that a type can have and prevent others from extending or implementing it in a way that is not intended.

Versiegelte Klassen ermöglichen es dem Compiler auch, zur Kompilierzeit Fehler zu generieren, wenn Sie versuchen, einen nicht versiegelten Typ in einen nicht zulässigen Untertyp zu konvertieren. Java 17 bringt auch eine neue Rendering-Pipeline für AWT/Swing-Apps, die auf macOS laufen und die Apple Metal API anstelle von OpenGL verwenden. Es verfügt über eine verbesserte API und erweiterte Funktionen zum Generieren von Zufallszahlen.

Änderungen, Löschungen und Einschränkungen in Java 17

Java 17 bringt auch mehrere Änderungen, Löschungen und neue Einschränkungen mit sich.

Kapselung von JDK-Interna

Eine Änderung ist der Abschluss des Kapselungsprozesses von JDK Internals. Dies wurde zum ersten Mal in Java 9 eingeführt und gab während der Laufzeit Warnungen aus, wenn ein Benutzer versuchte, Reflection oder ähnliches zu verwenden, um die üblichen Einschränkungen bei der Verwendung von internal zu umgehen APIs. Befehlszeilenargumente wurden ebenfalls hinzugefügt, um dieses Verhalten zu regulieren.

Ab Java 9 wurden verschiedene APIs erstellt, um eine einheitliche Möglichkeit zu bieten, die am häufigsten verwendeten Aufgaben zu erledigen; Benutzer würden diese APIs intern verwenden. Mit Java 16 wurde die Standardeinstellung von einer Warnung in die Deaktivierung des Zugriffs zum Auslösen einer Ausnahme geändert. Es verwendet jedoch das Befehlszeilenargument, um das Verhalten zu ändern.

Mit Java 17 entfällt das Kommandozeilenargument, und es ist möglich, diese Einschränkung zu deaktivieren. Dies bedeutet, dass der gesamte nicht autorisierte Zugriff auf diese internen APIs jetzt geschützt ist.

Immer strenge Gleitkomma-Semantik

Eine weitere „Entfernung“ kann als Wiedereinführung der Always-Strict-Floating-Point-Semantik bezeichnet werden. Java 1.2 führte Änderungen an der Gleitkomma-Semantik-Standardeinstellung in Java ein, die es der JVM ermöglichen, bei Gleitkomma-Berechnungen eine winzige Genauigkeit einzutauschen, um die Leistung zu verbessern. In Klassen und Methoden, in denen strenge Semantik verwendet werden musste, u.a strictfp Stichwort wurde hinzugefügt. Seitdem wurden verschiedene Befehlssatztypen in die CPUs eingeführt, wodurch eine strikte Gleitkomma-Semantik ohne unnötige Kosten verwendet werden kann. Die Notwendigkeit, eine Standard- oder strikte Semantik zu implementieren, wurde eliminiert.

Java 17 removes the previous default semantics, and all floating-point operations are executed strictly. The term strictfpist noch vorhanden. Es hat jedoch keine Wirkung und verursacht eine Warnung bei kompilieren Zeit.

Ahead-of-Time (AOT) Zusammenstellung

Java 9 führte die AOT-Kompilierung (Ahead-of-Time) als experimentelle Funktion ein, die den Graal-Compiler verwendet, und ein JIT-Code wurde mit Java geschrieben. Java 10 machte den Graal-Compiler durch die Einbindung der JVMCI-Schnittstelle als JIT-Compiler in OpenJDK nutzbar. Seit seiner Veröffentlichung hat es eine enorme Verbesserung gegeben. Der Graal-Compiler hat enorme Fortschritte gemacht und hat seine JVM unter dem Namen GraalVM.

RMI-Aktivierung

RMI-Aktivierung wurde eliminiert in JEP407 nach der Entfernung aus Java 8 und schließlich veraltet und als Voraussetzung für die Entfernung in Java 15 gekennzeichnet. RMI-Aktivierung stellte eine Methode bereit, um verteilte Objekt-On-Demand-Ressourcen mithilfe von RMI zu aktivieren. Es wurde jedoch nur minimal verwendet, und in der Gegenwart ist eine bessere Alternative verfügbar. Der Rest des RMI bleibt von der Eliminierung des Aktivierungsanteils unberührt.

Entfernen der Applet-API

Die Applet-API wurde endlich zum Entfernen von . bestimmt JEP398, ursprünglich in Java 9 entfernt. Die Applet-API bot eine Möglichkeit, Java AWT/Swing-Steuerelemente in eine Webseite innerhalb eines Browsers zu integrieren. Dies kann jedoch kein moderner Browser unterstützen, was bedeutet, dass Applets in den letzten zehn Jahren im Wesentlichen nicht zugänglich waren.

Security Manager

Die wichtigste Einstellung ist der Sicherheitsmanager ( JEP411). Security Manager ist seit Java 1.0 eine Weile im Einsatz. Es wurde entwickelt, um einzuschränken, was Java lokal auf dem Computer tun kann, beispielsweise den Zugriff auf Netzwerke, Dateien und andere Netzwerkressourcen einzuschränken. Es versucht auch, Code, dem nicht vertrauenswürdig ist, in eine Sandbox zu überführen, indem die Reflektion und bestimmte APIs blockiert werden.

Das Ende von Security Manager begann in Java 12. Ein Befehlszeilenargument wurde hinzugefügt, um die Verwendung des Security Managers zur Laufzeit zu blockieren. Die in Java 17 vorgenommene Änderung bedeutet, dass in der JVM eine Laufzeitwarnung generiert wird, wenn versucht wird, einen Sicherheitsmanager zu setzen, entweder über die Befehlszeile oder dynamisch zur Laufzeit.

Incubator and Preview Features

Many wondered whether Java 17 would have any preview and incubator features, considering that Java 17 was promoted to be a long-term supported version. Java 17 has two incubator modules and a preview feature!

Vektor-API

Vektor-API ( JEP414) befindet sich derzeit in der zweiten Phase des Inkubators. Die API ermöglicht es Entwicklern, Vektorberechnungen zu definieren, die der JIT-Compiler dann in die entsprechenden Vektorbefehle umwandelt, die von der CPU-Architektur unterstützt werden, auf der die JVM ausgeführt wird (z. B. unter Verwendung der Befehlssätze SSE oder AVX).

Zuvor mussten Entwickler skalare Funktionen verwenden oder native Bibliotheken erstellen, die spezifisch für die Plattform waren. Die Implementierung der Vector-API in Java bietet auch einen nahtlosen Fallback-Mechanismus, der in früheren Versionen kompliziert war.

Die Standardisierung der Vector API ermöglicht es den Klassen innerhalb des JDK, diese zu verwenden. Die mismatch()-Methoden von Java-Arrays könnten so geändert werden, dass sie stattdessen auf Java ausgeführt werden, wodurch die Notwendigkeit entfällt, mehrere plattformspezifische Implementierungen innerhalb der JVM zu verwalten und zu schreiben.

Fremdfunktions- und Speicher-API

Eine zusätzliche Inkubatorfunktion wird als Foreign Function & Memory API ( JEP412). Es ist eine Weiterentwicklung und Verschmelzung von zwei anderen Inkubatormodulen von Java 16, die The Foreign Linker API ( JEP389) und Fremdspeicher-API ( JEP393). Beide bieten Zugriff auf nativen Speicher und Code, indem sie in Java geschriebene statisch typisierte Programmierung verwenden.

Musterabgleich für Schalter

The final feature of the language preview included in Java 17 is the inclusion of Pattern Matching for Switch ( JEP406). Diese Sprachfunktion erweitert die Switch-Ausdrücke und -Anweisungen nach Typ, ähnlich der Syntax, die beim Pattern Matching verwendet wird (JEP394), die mit Java 16 zum Standard wurde.

Wenn Sie in der Vergangenheit verschiedene Aktionen basierend auf der dynamischen Natur eines Objekts ausführen wollten, mussten Sie eine Wenn-Sonst-Kette mit einer Instanz von Prüfungen erstellen, wie zum Beispiel:

String type(Object o) {
  if (o instanceof List) {
    return "A List of things.";
  }
  else if (o instanceof Map) {
    return "A Map! It has keys and values.";
  }
  else if (o instanceof String) {
    return "This is a string.";
  }
  else {
    return "This is something else.";
  }
}

Durch die Kombination des Switch-Ausdrucks sowie der neuen Pattern-Matching-Funktion für Switches kann der Prozess auf Folgendes reduziert werden:

String type(Object o) {
  return switch (o) {
    case List l -> "A List of things.";
    case Map m -> "A Map! It has keys and values.";
    case String s -> "This is a string.";
    default -> "This is something else.";
  };
}

Wie Sie vielleicht bemerkt haben, wird gerade eine Variable deklariert. Wie bei den anderen Variablen in Pattern zeigt die Übereinstimmung von Instanzen an, dass dieses Objekt einer Typprüfung und Umwandlung unterzogen wurde und von der Variablen in seinem aktuellen Bereich verfügbar ist.

Die preview function is another step towards pattern matching. The next step is to include the capability of deconstructing arrays and records.

Sollten Sie auf Java 17 upgraden?

Ja, Sie müssen ständig auf die neueste Version aktualisieren, jedoch nicht gleich am ersten Tag. Die von Ihnen verwendete Software und Bibliotheken wurden möglicherweise nicht aktualisiert, um die Kompatibilität mit Java 17 zu gewährleisten, sodass Sie möglicherweise einige Zeit warten müssen, bis dies abgeschlossen ist.

Wenn Sie mit einer LTS-Version von Java wie Java 8 oder Java 11 nicht weiterkommen, gibt es zahlreiche Optionen innerhalb der Sprache und innerhalb der JVM selbst, die ein Upgrade auf Java 17 erfordern. Da es sich um eine langfristige Wartungsversion handelt, gibt es eine hohe Wahrscheinlichkeit, dass Ihre Produktionsumgebung irgendwann auch auf Java 17 aktualisiert wird.

Wenn Sie ein völlig neues Projekt beginnen oder gerade dabei sind, Ihr Projekt auf Java 17 vorzubereiten, ist es wahrscheinlich am effizientesten, früher oder später auf Java 17 umzusteigen, da es die Umzugskosten reduziert. Dies ermöglicht es den Entwicklern, die an dem Projekt arbeiten, auch die neuesten Funktionen und die Ops-Seite zu nutzen.

Sie können von den vielen Verbesserungen profitieren, die in den letzten Jahren vorgenommen wurden, wie z.