Nach sechs Monaten Entwicklungszeit hat Oracle die Plattform Java SE 18 (Java Platform, Standard Edition 18) veröffentlicht, wobei das OpenJDK-Projekt als Referenzimplementierung dient. Abgesehen von der Entfernung einiger veralteter Funktionen bleibt Java SE 18 vollständig abwärtskompatibel zu vorherigen Versionen der Java-Plattform – die meisten zuvor entwickelten Java-Projekte werden ohne Änderungen unter der neuen Version problemlos funktionieren. Die Installationspakete für Java SE 18 (JDK, JRE und Server JRE) sind für Linux (x86_64, AArch64), Windows (x86_64) und macOS (x86_64, AArch64) verfügbar. Die im Rahmen des OpenJDK-Projekts entwickelte Referenzimplementierung von Java 18 steht komplett unter der GPLv2-Lizenz mit Ausnahmen für GNU ClassPath, die das dynamische Linking mit kommerziellen Produkten erlauben.
Java SE 18 gehört zur Kategorie der Releases mit regulärer Unterstützung, für die Updates bis zur nächsten Version bereitgestellt werden. Für langfristige Unterstützung (LTS) sollte Java SE 17 verwendet werden, dessen Updates bis 2029 verfügbar sein werden. Es ist wichtig zu beachten, dass mit der Veröffentlichung von Java 10 das Projekt auf einen neuen Entwicklungsprozess umgestiegen ist, der einen kürzeren Zyklus für die Erstellung neuer Releases umfasst. Neue Funktionen werden jetzt in einem kontinuierlich aktualisierten Master-Branch entwickelt, in den fertige Änderungen integriert werden, und von dem alle sechs Monate Branches für die Stabilisierung neuer Releases abgezweigt werden.
Neuigkeiten in Java 18 umfassen:
- Standardmäßig wird die Codierung UTF-8 verwendet. Java-APIs, die Textdaten unter Berücksichtigung der Zeichencodierung verarbeiten, werden nun standardmäßig UTF-8 auf allen Plattformen verwenden, unabhängig von den Systemeinstellungen und der festgelegten Gebietsschema. Um das alte Verhalten zurückzugeben, bei dem die Codierung basierend auf dem Systemschema ausgewählt wird, kann der Parameter „-Dfile.encoding=COMPAT“ verwendet werden.
- Im Paket com.sun.net.httpserver ist das Dienstprogramm jwebserver enthalten, das eine Bibliotheks-API mit einer Implementierung eines einfachen HTTP-Servers für die Bereitstellung statischer Inhalte umfasst (CGI- und servlet-ähnliche Handler werden nicht unterstützt). Der integrierte HTTP-Server ist nicht für Arbeitslasten optimiert und unterstützt kein Zugriffsmanagement oder Authentifizierung, da er hauptsächlich für die Verwendung während des Entwicklungsprozesses zur Prototypenerstellung, Debugging und Testen von Projekten gedacht ist.
- In JavaDoc wird das Tag „@snippet“ unterstützt, um Arbeitsbeispiele und Codefragmente in die API-Dokumentation einzubetten, auf die Prüfwerkzeuge zur Korrektheit, Syntaxhervorhebung und Integration mit IDEs angewendet werden können.
- Die Implementierung der API java.lang.reflect (Core Reflection) wurde überarbeitet, die zur Beschaffung von Informationen über Methoden, Felder und Konstruktoren von Klassen sowie zum Zugriff auf die interne Struktur von Klassen gedacht ist. Die API java.lang.reflect selbst bleibt unverändert, wurde jedoch nun durch die Verwendung von Methodendeskriptoren (Method Handles), die vom Modul java.lang.invoke bereitgestellt werden, anstelle von Bytecode-Generatoren implementiert. Diese Änderung hat es ermöglicht, die Implementierungen von java.lang.reflect und java.lang.invoke zu standardisieren und deren Wartung zu vereinfachen.
- Eine dritte vorläufige Implementierung der API Vector wurde vorgeschlagen, die Funktionen für vektorielle Berechnungen bereitstellt, die unter Verwendung von Vektorbefehlen der Prozessoren x86_64 und AArch64 durchgeführt werden und es ermöglichen, Operationen gleichzeitig auf mehrere Werte (SIMD) anzuwenden. Im Gegensatz zu den vom JIT-Compiler HotSpot angebotenen Auto-Vektorisierungsfunktionen für skalare Operationen bietet die neue API die Möglichkeit, die Vektorisierung für die parallele Datenverarbeitung explizit zu steuern.
- Ein SPI-Interface (Service-Provider-Interface) zur Auflösung von Hostnamen wurde hinzugefügt und IP-Adressen, der es ermöglicht, alternative Resolver in java.net.InetAddress zu verwenden, die unabhängig von den von dem Betriebssystem angebotenen Handlern sind.
- Eine zweite vorläufige Implementierung der API für ausländische Funktionen und Speicher wurde vorgeschlagen, mit der Anwendungen mit Code und Daten interagieren können, die außerhalb der Java-Laufzeit liegen. Die neue API ermöglicht es, Funktionen, die nicht in der JVM ausgeführt werden, effizient aufzurufen und auf Speicher zuzugreifen, der nicht von der JVM verwaltet wird. Beispielsweise können Funktionen aus externen Shared Libraries aufgerufen und auf Prozessdaten zugegriffen werden, ohne JNI verwenden zu müssen.
- Eine zweite experimentelle Implementierung der Musterabgleichung in 'switch'-Ausdrücken wurde hinzugefügt, die es ermöglicht, in 'case'-Labels keine exakten Werte, sondern flexible Muster zu verwenden, die sofort eine Reihe von Werten abdecken, für die zuvor umständliche 'if…else'-Ausdrucksfolgen 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(); };
- Der Mechanismus zur Finalisierung, einschließlich damit verbundener Methoden wie Object.finalize(), Enum.finalize(), Runtime.runFinalization() und System.runFinalization(), wird als veraltet angesehen und in einer der nächsten Versionen entfernt.
- Die Garbage Collector ZGC (Z Garbage Collector), SerialGC und ParallelGC unterstützen die Deduplication von Strings.
Quelle: opennet.ru
