Java 18 erschienen
Heute ist Java 18 erschienen. Tatsächlich handelt es sich dabei bereits um das 19. Major Release, was der anfänglichen Zählweise 1.0, 1.1, 1.2 usw. geschuldet ist. Die Neuerungen, die Java 18 mit sich bringt, fasse ich in diesem Artikel zusammen.
JEP-400: UTF-8 by Default
Viele Funktionen in der Java-Standard-API, die z.B. dem Lesen und Schreiben von Dateien dienen, verwenden bislang standardmäßig ein systemabhängiges Charset, sofern in den entsprechenden Methoden nicht explizit eines angegeben wird. Ab Java 18 wird in diesem Fall nun stets UTF-8 verwendet. Dies eliminiert ein Hindernis, das Javas erklärtem Ziel „write once, run anywhere“ bisher noch im Weg stand. Außerdem sorgt es für mehr Konsistenz innerhalb der Standard-API, da es dort bereits Funktionalitäten gibt, die standardmäßig UTF-8 verwenden (wie etwa die Methoden in java.nio.file.Files).
JEP-408: Simple Web Server
Java 18 bringt einen neuen, einfachen HTTP-Server mit, der statische Dateien ausliefert. Er kann entweder via API aus einem Java-Programm heraus, als auch über das Kommandozeilentool jwebserver gestartet werden. Er soll eine unkomplizierte Alternative darstellen für Fälle, in denen eine einfache Serverfunktionalität benötigt wird, wie z.B. im Bildungsbereich, in der Webentwicklung, für Tests o.ä..
JEP-413: Code Snippets in Java API Documentation
Dokumentationen von Java-APIs enthalten oft Codebeispiele. Die bisherigen Mittel, um Code im JavaDoc zu zeigen, sind jedoch recht unzulänglich. Unter anderem wird der Code nicht validiert, was unter Umständen unbemerkt zu Fehlern führen kann. Oder einstmals gültiger Code wird durch Sprachänderungen ungültig. Zudem ist kein Syntax-Highlighting möglich. Dem wird nun abgeholfen mit einem {@snippet ...}-Tag, mit dem Codeschnipsel ins JavaDoc eingeschlossen werden können. Die Codefragmente können entweder inline sein, d.h. innerhalb des snippet-Tags stehen, oder extern, also mit Verweis auf eine andere Datei, in welcher der einzuschließende Code mit @start– und @end-Tags innerhalb von Kommentaren markiert ist:
/**
* The following code shows how to use {@code Optional.isPresent}:
* {@snippet :
* if (v.isPresent()) {
* System.out.println("v: " + v.get());
* }
* }
*/
/**
* The following code shows how to use {@code Optional.isPresent}:
* {@snippet file="ShowOptional.java" region="example"}
*/
public class ShowOptional {
void show(Optional<String> v) {
// @start region="example"
if (v.isPresent()) {
System.out.println("v: " + v.get());
}
// @end
}
}
Durch das ebenfalls neue Tag @highlight ist es möglich, Stellen im Code hervorzuheben. Außerdem kann der Code mittels @replace für die Darstellung in der Dokumentation modifiziert werden.
JEP-416: Reimplement Core Reflection with Method Handles
In Javas Reflection-Funktionalität gibt es derzeit drei unterschiedliche Mechanismen zum dynamischen Aufruf von Methoden oder Konstruktoren. Bei der Einführung neuer Sprachfeatures in diesem Bereich, wie z.B. für das Projekt Valhalla, müssen alle drei Mechanismen jeweils separat unterstützt werden. Das ist kostenintensiv, daher wird eine der Varianten, die dynamische Bytecodeerzeugung verwendet, mithilfe von Method Handles neu implementiert.
JEP-417: Vector API (Third Incubator)
Mit der Vector API führt Java die plattformübergreifende Unterstützung zur Entwicklung datenparalleler Algorithmen ein. Anhand eines „Single Instruction Multiple Data“ (SIMD) Modells sollen die Vector-Instruktionen unterschiedlicher CPU-Architekturen unterstützt werden. Anwendungsfälle hierfür sind etwa die Bild- und Videoverarbeitung. In dieser dritten Inkubation wurde u.a. die Unterstützung für die ARM Scalar Vector Extension (SVE) hinzugefügt.
JEP 418: Internet-Address Resolution SPI
Hinzufügen eines Service Provider Interfaces (SPI) für die Auflösung von Hostnamen und IP-Adressen. Die API verwendet derzeit den systemeigenen Resolver des Betriebssystems. Über das SPI können nun weitere Resolver hinzugefügt werden. Zum Beispiel eine nicht-blockierende Variante, damit die mit Project Loom eingeführten virtuellen Threads nicht behindert werden, wenn der OS-Thread, auf dem sie operieren, durch Auflösungsanfragen blockiert. Ein weiteres Szenario kann das automatisierte Testen von Funktionen sein, die auf der Auflösung von Hostnamen basieren.
JEP 419: Foreign Function & Memory API (Second Incubator)
Einführung einer API, über die Java-Programme mit Code und Daten außerhalb der Java-Laufzeitumgebung interagieren können. Durch den effizienten Aufruf fremder Funktionen (d.h. Code außerhalb der JVM) und den sicheren Zugriff auf fremden Speicher (d.h. Speicher, der nicht von der JVM verwaltet wird) ermöglicht die API Java-Programmen den Aufruf nativer Bibliotheken und die Verarbeitung nativer Daten ohne die Fragilität und die Gefährlichkeit von JNI (Java Native Interface). Mit der Entwicklung dieser API soll JNI abgelöst werden.
JEP 420: Pattern Matching for switch (Second Preview)
Pattern Matching for switch geht mit Java 18 in die zweite Preview. Über dieses Feature hatte ich schon in meinem Blogbeitrag Java 17 (LTS) am Horizont berichtet. Die 2. Preview zieht ein paar Details bzgl. Prüfung der case-Labels und Vollständigkeit von switch-Blöcken nach. Die Berücksichtigung aller Feinheiten ist alles andere als einfach, daher wurde bereits eine dritte Preview angekündigt. Somit wird die fertige Funktionalität wohl nicht vor Java 20 Einzug in die Sprache finden.
JEP 421: Deprecate Finalization for Removal
Die in Java 1.0 eingeführte Finalization sollte helfen, Ressourcenlecks zu vermeiden. Was sich theoretisch gut anhört, hat sich in der Praxis aufgrund der Schwachstellen bei der Umsetzung nicht bewährt. Schon bald nach der Einführung wurde daher vom Einsatz von Finalizern abgeraten, z.B. in Joshua Blochs 2001 erschienenem Buch „Effective Java“. Aus diesem Grund werden Finalizer ab Java 18 als „Deprecated“ markiert, um die Entfernung in einem späteren Java-Release vorzubereiten.
