48 VIEWS

Java 17 (LTS) am Horizont

03.09.2021

Es ist nicht mehr lange hin: am 14.09.2021 erscheint Java 17, das nächste LTS-Release der Programmiersprache. Lest hier eine Zusammenfassung darüber, was das neue Release so alles mit sich bringt.

Java 17 (LTS) kommt

Drei Jahre ist es her, dass mit Version 11 das letzte Long-Term-Support-Release (LTS) von Java erschienen ist. In Kürze, genau gesagt am 14.09.2021, erscheint Java 17, das nächste LTS-Release.

Die folgenden Neuerungen sind mit dabei.

JEP 306: Restore Always-Strict Floating-Point Semantics

Aufgrund von ein paar „bedauerlichen Eigentümlichkeiten“ der damals beliebten x86-Rechnerarchitektur wurde in den späten 1990’ern die Standardsemantik von Fließkommazahl-Operationen angepasst. Da die ausschlaggebenden Eigenheiten in den heutigen Hardwarearchitekturen keine Relevanz mehr haben, wird die Semantik auf den ursprünglichen „always-strict“-Modus zurück gesetzt.

JEP 356: Enhanced Pseudo-Random Number Generators

Es werden neue Interfaces und Implementierungen für (Pseudo-)Zufallszahlengeneratoren wie java.util.Random bereitgestellt. Dadurch wird es u.a. leichter, Implementierungen auszutauschen und mit Zufallszahlgeneratoren in der Stream-API zu arbeiten. Zudem kann duplizierter Code in den existierenden Klassen eliminiert werden. Das Verhalten der Random-Klasse wird dabei auf jeden Fall beibehalten.

JEP 398: Deprecate the Applet API for Removal

Da alle Hersteller von Webbrowsern die Unterstützung von Applets beendet oder das Ende der Unterstützung angekündigt haben, wird die Applet-API nicht mehr benötigt und soll daher aus dem JDK entfernt werden. In Java 17 wird die API zunächst auf „Deprecated for Removal“ gesetzt.

JEP 411: Deprecate the Security Manager for Removal

Die primäre Funktion des SecurityManagers war die Absicherung von Applet-Code, der von Webbrowsern auf den Rechner des Benutzers heruntergeladen und dort ausgeführt wurde. Die Applets wurden in einer Sandbox ausgeführt, von der aus kein Zugriff auf das Dateisystem oder Netzwerk des Rechners möglich war, auf dem sie liefen. Durch den Wegfall von Applets wird auch der SecurityManager obsolet, daher wird dieser ebenfalls für spätere Entfernung in den Status „Deprecated for Removal“ versetzt.

JEP 403: Strongly Encapsulate JDK Internals

Bis auf wenige Ausnahmen sollen alle internen Klassen, Methoden und Felder im JDK gekapselt werden, so dass diese nicht mehr von außerhalb genutzt werden können. Viele Frameworks und Bibliotheken haben diese Elemente, die eigentlich nur für JDK-interne Belange gedacht sind, genutzt bzw. nutzen diese noch immer. Allerdings leiden dadurch Wartbarkeit und Sicherheit des JDK. Daher ist es ab Java 17 nicht mehr möglich, die Nutzung dieser Elemente via Kommandozeilenparameter freizuschalten. Die Entwickler sollen so motiviert werden, entsprechende Funktionalitäten auf Standard-APIs umzustellen. Eine Ausnahme ist die berühmte Klasse sun.misc.Unsafe, für die es noch keine alternative API gibt.

JEP 409: Sealed Classes

Erweitert die Programmiersprache um „versiegelte“ Klassen und Interfaces. Damit können Entwickler bestimmen, welche Untertypen einer Klasse oder eines Interface es geben darf:

Dies macht es unmöglich, weitere Klassen oder Interfaces zu schreiben, die von der Klasse Shape erben. Unter anderem ist dies nützlich für den Compiler, der nun weiß dass ein Shape nur ein Circle, Rectangle oder Square sein kann. In einem switch-Ausdruck ist dann kein default-case mehr nötig, wenn alle unter permits aufgeführten Typen durch case-Labels abgedeckt sind.

JEP 406: Pattern Matching for switch (Preview)

In Java 16 wurde mit JEP 394 Pattern Matching for instanceof eingeführt. Als nächste Stufe folgt nun Pattern Matching für switch:

Ist das geprüfte Element von einem der als case aufgeführten Typen, erfolgt ein automatischer Cast, so dass auf der rechten Seite der entsprechende Typ direkt verwendet wird. Neu ist dass als case auch null verwendet werden kann, um eine NullPointerException zu verhindern. Handelt es sich beim Selektor um einen „versiegelten“ Typ (s.o. unter Sealed Classes) und alle möglichen Ausprägungen sind in den cases aufegührt, kann der default-case weggelassen werden (wie es mit enums auch schon möglich ist).

JEP 412: Foreign Function & Memory API (Incubator)

Das Java Native Interface (JNI) zum Aufruf von C-Funktionen wird durch eine neue API ersetzt, die rein Java-basiert ist und somit beispielsweise ohne C-Headerdateien auskommt. Zudem erlaubt die API auch Zugriff auf fremde Funktionen, die nicht in C geschrieben sind (z.B. C++ oder Fortran).

Eine weitere API soll Zugriff auf Speicherbereiche erlauben, die außerhalb des JVM-Heaps liegen, um beispielsweise hochperformante Anwendungen zu entwickeln. Hierfür wird derzeit sun.misc.Unsafe verwendet, was jedoch gefährlich ist, weil damit auf alle Speicherbereiche zugegriffen werden kann. Dies kann bei falscher Verwendung u.a. die JVM zum Absturz bringen. Daher wird von der Nutzung von sun.misc.Unsafe dringlich abgeraten, weshalb die neue API als Alternative angeboten werden soll.

Sonstiges

Unter JEP 410 werden die experimentellen Java-basierten AOT- und JIT-Compiler entfernt. JEP 414 führt eine plattformunabhängige API für Vektor-Berechnungen ein, mit der entsprechende Hardwareunterstützung vorausgesetzt, hochperformante Berechnungen durchgeführt werden können. Durch JEP 382 und JEP 391 soll die JDK-Unterstützung auf macOS-Hardwareplattformen verbessert werden. Und JEP 415 bringt kontextspezifische und dynamisch ausgewählte Filter, die die Deserialisierung von Objekten aus unzuverlässigen Quellen sicherer machen sollen.

Zurück zur Übersicht

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*Pflichtfelder

*