© Enkel/Shutterstock.com
Infografik

Java 14: Diese JEPs sind Teil des JDKs


Duke_1.png

JEP 305 – Pattern Matching for instanceof (Preview)

Im Zuge des Projekts Amber wird unter anderem am sogenannten Pattern Matching für Java gearbeitet. Für den Operator instanceof wird das Pattern Matching in Java 14 Wirklichkeit. Durch Pattern Matching soll die Programmiersprache Java prägnanter und sicherer werden. Die „Form“ von Objekten kann so präzise definiert werden, woraufhin diese dann von Statements und Expressions gegen den eigenen Input getestet werden. Die Nutzung von Pattern Matching in instanceof könnte für einen starken Rückgang nötiger Typumwandlungen in Java-Anwendungen sorgen. In zukünftigen Java-Versionen soll das Pattern Matching für weitere Sprachkonstrukte wie Switch Expressions kommen.

Duke_2.png

JEP 343 – Packaging Tool

Wer hätte gedacht, dass man JavaFX vielleicht doch noch einmal vermissen würde? Mit JDK 8 wurde auch das Tool javapackager veröffentlicht, das als Teil von JavaFX im Kit enthalten war. Nachdem JavaFX allerdings mit dem Release von JDK 11 aus Java herausflog, war auch der beliebte javapackager nicht mehr verfügbar. Das Packaging-Tool sorgte dafür, dass Java-Anwendungen so verpackt werden konnten, dass sie wie alle anderen Programme installiert werden konnten. Für Windows-Nutzer konnten so etwa *.exe-Dateien erstellt werden, deren enthaltene Java-Anwendung dann per Doppelklick installiert wurde. Da das Tool schmerzlich vermisst wird, wird ein neues Werkzeug mit Namen jpackage dessen Aufgabe übernehmen. Nutzer können so endlich wieder eigenständige Java-Installationsdateien erstellen, deren Basis die Java-Anwendung und ein Laufzeit-Image sind. Das Tool nimmt diesen Input und erstellt ein Image einer Java-Anwendung, die sämtliche Abhängigkeiten enthält (Formate: msi, exe, pkg in dmg, app in dmg, deb und rpm).

Duke_3.png

JEP 345 – NUMA-Aware Memory Allocation for G1

Mehrkernprozessoren sind mittlerweile der allgemeine Standard. In einer NUMA-Arbeitsspeicher-Architektur erhält jeder Kern des Prozessors einen lokalen Arbeitsspeicher, auf den den anderen Kernen allerdings Zugriff gewährt wird. JEP 345 sieht vor, den G1 Garbage Collector mit der Möglichkeit auszustatten, solche Architekturen vorteilhaft zu nutzen. So soll unter anderem die Performance auf sehr leistungsstarken Maschinen erhöht werden. JEP 345 dient dabei ausschließlich der Implementierung des NUMA-Supports für den G1 Garbage Collector, nur für das Speichermanagement (Memory Allocation) und auch nur unter Linux. Ob also diese Unterstützung von NUMA-Architekturen auch für andere Garbage Collectors kommt oder für andere Teile wie etwa das Task Queue Stealing, ist nicht bekannt.

Duke_4.png

JEP 349 – JFR Event Streaming

Der Java Flight Recorder (JFR) ist mittlerweile Teil des OpenJDKs und damit frei verfügbar. Mit JEP 349 wurde vorgeschlagen, ein API zu erstellen, über das die vom Java Flight Recorder erhobenen Daten für die kontinuierliche Überwachung von aktiven und inaktiven Anwendungen genutzt werden können. Dabei sollen die gleichen Events aufgenommen werden wie bei der Nicht-Streaming-Variante; der Overhead soll weniger als ein Prozent betragen. Event Streaming würde so mit der Nicht-Streaming-Variante gleichzeitig durchgeführt werden. Die in JEP 349 eingeführte Funktion soll allerdings keine synchronen Callbacks für den jeweiligen Konsumenten ermöglichen, auch Daten aus Recordings, die im Zwischenspeicher liegen, sollen nicht verfügbar gemacht werden. Technisch würde das Package jdk.jfr.consumer im Modul jdk.jfr durch die Funktionalität erweitert werden, asynchron auf Events zugreifen zu können.

Duke_5.png

JEP 352 – Non-Volatile Mapped Byte Buffers

Mit JEP 352 wird der MappedByteBuffer um die Fähigkeit erweitert, den Zugriff auf nichtflüchtige Datenspeicher (NVMs) zu erweitern. Diese Speicher (auch als persistente Speicher bekannt) werden eingesetzt, um Daten dauerhaft zu speichern. Das Java Enhancement Proposal hat in Bezug auf das JDK API ein neues Modul und eine neue Klasse im Gepäck: Das Modul jdk.nio.mapmode kann genutzt werden, um den MappedByteBuffer zu erstellen (read-write oder read-only), der über eine Datei auf einem NVC gemappt ist. Die Klasse ManagementFactory macht es möglich, eine Liste von BufferPoolMXBean-Instanzen über die Methode List<T> getPlatformMXBeans(Class<T>) ...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang