Nach sechsmonatiger Entwicklung hat Oracle die Plattform Java SE 18 (Java Platform, Standard Edition 18) veröffentlicht, deren Referenzimplementierung das Open-Source-Projekt OpenJDK nutzt. Abgesehen von der Entfernung einiger veralteter Funktionen bleibt die Abwärtskompatibilität zu früheren Java-Versionen in Java SE 18 erhalten – die meisten zuvor geschriebenen Java-Projekte werden ohne Änderungen unter der neuen Version lauffähig sein. Fertige Installationspakete von Java SE 18 (JDK, JRE und Server JRE) sind für Linux (x86_64, AArch64), Windows (x86_64) und macOS (x86_64, AArch64) vorbereitet. Die im Rahmen des OpenJDK-Projekts entwickelte Referenzimplementierung von Java 18 ist vollständig unter der GPLv2-Lizenz mit Ausnahmen für GNU ClassPath, die dynamisches Binden an kommerzielle Produkte erlauben.
Java SE 18 gehört zur Kategorie der Versionen mit regulärer Unterstützung, für die Updates bis zur nächsten Veröffentlichung bereitgestellt werden. Als LTS-Branch (Long Term Support) sollte Java SE 17 verwendet werden, dessen Updates bis 2029 bereitgestellt werden. Beachten Sie, dass mit der Veröffentlichung von Java 10 das Projekt auf einen neuen Entwicklungsprozess umgestiegen ist, der kürzere Zyklen zur Erstellung neuer Versionen vorsieht. Neue Funktionen werden jetzt in einem ständig aktualisierten Master-Branch entwickelt, in den bereits fertige Änderungen einfließen, von dem zweimal pro Jahr Branches zur Stabilisierung neuer Versionen abgezweigt werden.
Zu den Neuerungen in Java 18 gehören:
- Standardmäßig wird die Kodierung UTF-8 verwendet. Java-APIs, die Textdaten unter Berücksichtigung der Zeichencodierung verarbeiten, verwenden nun standardmäßig UTF-8 auf allen Plattformen, unabhängig von den Systemeinstellungen und der gesetzten Lokalisierung. Um das alte Verhalten, bei dem die Kodierung unter Berücksichtigung der systemeigenen Lokalisierung ausgewählt wird, wiederherzustellen, kann der Parameter "-Dfile.encoding=COMPAT" verwendet werden.
- Das Paket com.sun.net.httpserver ist enthalten, das das jwebserver-Dienstprogramm sowie eine bibliothekarische API mit einer Implementierung eines einfachen HTTP-Servers zur Bereitstellung statischer Inhalte (CGI- und servletähnliche Handler werden nicht unterstützt) umfasst. Der integrierte HTTP-Server ist nicht für Arbeitslasten optimiert und unterstützt kein Zugriffsmanagement und keine Authentifizierung, da er hauptsächlich für die Nutzung während des Entwicklungsprozesses zur Erstellung von Prototypen, Debugging und Testen von Projekten gedacht ist.
- In JavaDoc wurde die Unterstützung des Tags „@snippet“ implementiert, das die Einbettung von Arbeitsbeispielen und Codefragmenten in die API-Dokumentation ermöglicht, für die Tools zur Überprüfung der Korrektheit, Syntax-Hervorhebung und Integration mit IDEs verwendet werden können.
- Die Implementierung der API java.lang.reflect (Core Reflection), die zum Abrufen von Informationen über Methoden, Felder und Konstruktoren von Klassen sowie zum Zugriff auf die interne Struktur von Klassen dient, wurde überarbeitet. Die API java.lang.reflect bleibt unverändert, wird jedoch jetzt durch die Verwendung von Methodenhandles, die vom Modul java.lang.invoke bereitgestellt werden, anstelle von Bytecode-Generatoren implementiert. Diese Änderung ermöglicht eine Vereinheitlichung der Implementierungen von java.lang.reflect und java.lang.invoke und vereinfacht deren Wartung.
- Eine dritte Vorab-Implementierung der API Vector wurde vorgeschlagen, die Funktionen für Vektorberechnungen bereitstellt, die unter Verwendung von Vektor-Anweisungen der Prozessoren x86_64 und AArch64 ausgeführt werden und es ermöglichen, Operationen gleichzeitig auf mehrere Werte anzuwenden (SIMD). Im Gegensatz zu den im JIT-Compiler HotSpot bereitgestellten Möglichkeiten zur automatischen Vektorisierung von Skalareingriffen bietet die neue API die Möglichkeit, die Vektorisierung für die parallele Verarbeitung von Daten explizit zu steuern.
- Ein SPI-Interface (Service-Provider-Interface) wurde hinzugefügt, um Hostnamen aufzulösen und IP-Adressen, das die Verwendung alternativer Resolver in java.net.InetAddress ermöglicht, die nicht an die von der Betriebssystem angebotenen Handler gebunden sind.
- Die zweite vorläufige Implementierung der Foreign Function & Memory API wurde vorgeschlagen, mit der Anwendungen mit Code und Daten außerhalb der Java-Laufzeitumgebung interagieren können. Die neue API ermöglicht es, Funktionen, die nicht in der JVM ausgeführt werden, effizient aufzurufen und auf nicht von der JVM verwalteten Speicher zuzugreifen. Beispielsweise können Funktionen aus externen gemeinsamen Bibliotheken aufgerufen und Prozessdaten ohne die Verwendung von JNI angesprochen werden.
- Eine zweite experimentelle Implementierung von Pattern Matching in "switch"-Ausdrücken wurde hinzugefügt, die es erlaubt, in "case"-Labels keine exakten Werte, sondern flexible Muster zu verwenden, die eine Serie von Werten abdecken, für die zuvor umständliche if…else-Ausdrücke verwendet werden mussten. Object o = 123L; String formatted = switch (o) { case Integer i -> String.format("int %d", i); case Long l -> String.format("long %d", l); case Double d -> String.format("double %f", d); case String s -> String.format("String %s", s); default -> o.toString(); };
- Das Finalisierungsverfahren wurde als veraltet erklärt und wird in einer der nächsten Versionen deaktiviert, ebenso wie die damit verbundenen Methoden wie Object.finalize(), Enum.finalize(), Runtime.runFinalization() und System.runFinalization().
- In den Garbage Collectors ZGC (Z Garbage Collector), SerialGC und ParallelGC wurde Unterstützung für die Duplikation von Strings implementiert.
Quelle: opennet.ru
