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
