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 Features
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 ist ein Feature, das in Java 17 eingeführt wurde. Das Sealed Classes Feature hat seine Testphase beendet und ist zu einer offiziellen Plattform und Sprache in Java 17 geworden. Es erlaubt einem Entwickler, die zulässigen Untertypen anzugeben, die ein Typ haben kann und andere daran hindern, es in einer nicht beabsichtigten Weise zu erweitern oder umzusetzen.
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.
Changes, Deletions, and Limitations 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 entfernt die bisherige Standardsemantik und alle Gleitkommaoperationen werden strikt ausgeführt. Der Begriff 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
Viele fragten sich, ob Java 17 Vorschau- und Inkubatorfunktionen haben würde, wenn man bedenkt, dass Java 17 als langfristig unterstützte Version beworben wurde. Java 17 hat zwei Inkubatormodule und eine Vorschaufunktion!
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
Die letzte Funktion der in Java 17 enthaltenen Sprachvorschau ist die Aufnahme von 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 Vorschaufunktion ist ein weiterer Schritt in Richtung Mustervergleich. Der nächste Schritt besteht darin, die Fähigkeit zum Dekonstruieren von Arrays und Datensätzen einzubeziehen.
Should You Upgrade to Java 17?
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.
