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 in Java 17 neu ist und ob Sie ein Upgrade durchführen sollten.
Viele Anwendungen verwenden ältere Versionen von Java, 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 Aufwand, hauptsächlich um das Beste aus den neuen Merkmalen und Funktionen innerhalb der JVM herauszuholen.
Viele Unternehmen verwenden Docker und Docker-Images, um mit minimalem Aufwand und Zeitaufwand einfach auf Java 17 umzustellen. Entwickler können ihre CI/CD-Pipelines (Continuous Integration/Deployment) 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.
Inhaltsverzeichnis
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 Prozessorserie (M1) unterstützen, die Apple im letzten Jahr mit seinen Computern herausgebracht hat.
Es ist nicht unbedingt eine große Sache für Benutzer auf diesen Plattformen, da einige Anbieter Versionen von JDK 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 zu gewährleisten 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 Feature Sealed Classes 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 verhindern, dass andere es in einer nicht beabsichtigten Weise erweitern oder implementieren.
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 Internals
Eine Änderung ist der Abschluss des Kapselungsprozesses von JDK Internals. Das erste Mal wurde dies in Java 9 eingeführt und gab während der Laufzeit Warnungen aus, wenn ein Benutzer versuchte, Reflektion oder ähnliches zu verwenden, um die üblichen Einschränkungen bei der Verwendung interner APIs zu umgehen. Befehlszeilenargumente wurden ebenfalls hinzugefügt, um dieses Verhalten zu regulieren.
Ab Java 9 wurden verschiedene APIs erstellt, um eine einheitliche Möglichkeit zum Ausführen der am häufigsten verwendeten Aufgaben zu bieten. Benutzer würden diese APIs intern verwenden. Mit Java 16 wurde die Standardeinstellung von einer Warnung zum Deaktivieren 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 besteht die Möglichkeit, diese Einschränkung zu deaktivieren. Das bedeutet, dass alle nicht autorisierten Zugriffe auf diese internen APIs jetzt geschützt sind.
Strikte Fließkomma-Semantik
Eine zusätzliche „Entfernung“ kann als Wiedereinführung der Always-Strict Floating Point-Semantik bezeichnet werden. Java 1.2 führte Modifikationen an der Standardeinstellung für die Gleitkomma-Semantik in Java ein, die es der JVM ermöglichen, eine winzige Menge an Genauigkeit in Gleitkomma-Berechnungen einzutauschen, um die Leistung zu verbessern. In Klassen und Methoden, in denen eine strenge Semantik verwendet werden musste, wurde ein Schlüsselwort strictfp 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 strenge Semantik zu implementieren, wurde eliminiert.
Java 17 entfernt die vorherige Standard-Semantik, und alle Gleitkommaoperationen werden strikt ausgeführt. Der Begriff „Strictfpis“ ist immer noch vorhanden. Es hat jedoch keine Auswirkung und führt zur Kompilierzeit zu einer Warnung.
Ahead-of-Time (AOT)-Zusammenstellung
Java 9 führte die Voraus-Kompilierung (AOT) als experimentelles Feature ein, das 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 der Veröffentlichung hat es sich enorm verbessert. Der Graal-Compiler hat enorme Fortschritte gemacht und hat seine JVM unter dem Namen GraalVM.
RMI-Aktivierung
Die RMI-Aktivierung wurde in entfernt JEP407 nach seiner Entfernung aus Java 8 und schließlich veraltet und als Voraussetzung für die Entfernung in Java 15 markiert. Die RMI-Aktivierung stellte eine Methode bereit, um verteilte Objekte bei Bedarf mit RMI zu aktivieren. Es wurde jedoch nur minimal genutzt, und in der Gegenwart ist eine bessere Alternative verfügbar. Der Rest des RMI bleibt von der Eliminierung des Aktivierungsanteils unberührt.
Applet-API-Entfernung
Die Applet-API wurde schließlich zum Entfernen bestimmt von 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. Kein moderner Browser kann dies jedoch unterstützen, was bedeutet, dass Applets in den letzten zehn Jahren im Wesentlichen nicht zugänglich waren.
Sicherheitsmanager
Die wichtigste Abwertung ist der Sicherheitsmanager ( JEP411). Security Manager ist seit Java 1.0 schon eine Weile im Einsatz. Es wurde entwickelt, um einzuschränken, was Java lokal auf dem Computer tun kann, z. B. den Zugriff auf Netzwerke, Dateien und andere Netzwerkressourcen einzuschränken. Es versucht auch, nicht vertrauenswürdigen Code in eine Sandbox einzuschließen, indem es die Reflektion und bestimmte APIs blockiert.
Das Ende des Sicherheitsmanagers begann in Java 12. Ein Befehlszeilenargument wurde hinzugefügt, um die Verwendung des Sicherheitsmanagers zur Laufzeit zu blockieren. Die in Java 17 vorgenommene Änderung bedeutet, dass in der JVM eine Laufzeitwarnung generiert wird, wenn versucht wird, einen Sicherheitsmanager festzulegen, entweder über die Befehlszeile oder dynamisch zur Laufzeit.
Inkubator- und Vorschaufunktionen
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 Vektoranweisungen umwandelt, die von der CPU-Architektur unterstützt werden, auf der die JVM ausgeführt wird (z. B. unter Verwendung der SSE- oder AVX-Anweisungssätze).
Früher mussten Entwickler Skalarfunktionen verwenden oder native Bibliotheken erstellen, die für die Plattform spezifisch 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, sie zu verwenden. Java Arrays mismatch()-Methoden 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 heißt Foreign Function & Memory API ( JEP412). Es ist eine Weiterentwicklung und Zusammenführung von zwei anderen Inkubatormodulen von Java 16, nämlich The Foreign Linker API ( JEP389) und Fremdspeicher-API ( JEP 393). Beide bieten Zugriff auf nativen Speicher und Code, indem sie in Java geschriebene statisch typisierte Programmierung verwenden.
Musterabgleich für Schalter
Das letzte Feature der in Java 17 enthaltenen Sprachvorschau ist die Einbeziehung von Pattern Matching für Switch ( JEP406). Diese Sprachfunktion erweitert die Switch-Ausdrücke und -Anweisungen nach Typ, ähnlich der Syntax, die beim Musterabgleich 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 if-else-Kette mit einer Instanz von Prüfungen erstellen, wie z. B.:
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 Kombinieren des Switch-Ausdrucks sowie der neuen Pattern-Matching-Funktion für Switches lässt sich der Prozess auf etwas Ähnliches reduzieren wie:
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, gibt es die Deklaration einer Variablen im Überprüfungsprozess. Wie bei den anderen Variablen in Pattern zeigt der Instanzabgleich an, dass dieses Objekt typgeprüft und umgewandelt wurde und von der Variablen in seinem aktuellen Bereich verfügbar ist.
Die Vorschaufunktion ist ein weiterer Schritt in Richtung Musterabgleich. Der nächste Schritt besteht darin, die Fähigkeit zum Dekonstruieren von Arrays und Datensätzen einzubeziehen.
Sollten Sie auf Java 17 upgraden?
Ja, Sie müssen ständig auf die neueste Version aktualisieren, jedoch nicht am ersten Tag. Die von Ihnen verwendete Software und Bibliotheken wurden möglicherweise nicht aktualisiert, um die Kompatibilität mit Java 17 einzuschließen, sodass Sie möglicherweise einige Zeit warten müssen, bis dies abgeschlossen ist.
Wenn Sie bei einer LTS-Version von Java wie Java 8 oder Java 11 festsitzen, 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 die effizienteste Wahl, eher früher als später auf Java 17 umzusteigen, da dies die Umzugskosten senkt. Dies ermöglicht es den Entwicklern, die an dem Projekt arbeiten, auch, alle neuesten Funktionen und die Ops-Seite zu nutzen.
Sie können von den vielen Verbesserungen profitieren, die in den letzten Jahren vorgenommen wurden, z. B. verbesserte Unterstützung für Container, die auf Java ausgeführt werden, sowie neue Garbage-Collector-Implementierungen mit geringer Latenz.