On the road again

Java 15 ist da! Text Blocks & Shenandoah GC verlassen Testphase

Dominik Mohilo

© Software & Support Media GmbH / Bianca Röder

 

Java 15 ist nun endlich als GA-Version verfügbar. Teil des neuen JDKs sind 14 JEPs (Spoiler Alert: Bye, Nashorn). Unter anderem verlassen die Text Blocks das experimentelle Stadium und auch der Shenandoah Garbage Collector ist nun vollwertiges Mitglied des JDK. Wir haben uns die JEPs des aktuellen Releases angesehen.

Neues Spiel, neues Glück: Auf Java 14 folgt – erwartungsgemäß – Java 15. Auch einige Features aus Projekt Valhalla oder Projekt Amber sind an Bord? Unsere Leser wird es freuen, wie ein Kommentar zeigt:

Neben Projekt Valhalla und Amber wird es auch für Panama und erst recht für Loom Zeit, Bestandteil vom offiziellen JDK zu werden. Mit Loom müsste in den meisten Fällen kein asynchroner Code mehr geschrieben werden. Endlich wieder synchron, blockierend und ohne die üblichen Nachteile.

Die Migration zu Git, die im Zuge von Projekt Skara geprüft wurde, wird nicht im Zuge von Java 15 stattfinden, dieser Umzug ist nämlich bereits erfolgt (JAXenter berichtete). Die entsprechenden JEPs (JEP 357: Migrate from Mercurial to Git & JEP 369: Migrate to GitHub) sind allerdings offiziell Teil von Java 16.

JDK 15: Diese JEPs sind Teil des Releases

Die folgenden JEPs machen Java 15 aus und sind Teil des JDKs. Nachdem bereits das Datum (15. September) gut zu Java 15 gepasst hat, wäre es schön gewesen, wenn auch 15 JEPs Teil des neuen JDKs gewesen wären. Ziel knapp verfehlt: Es sind leider nur 14, doch die können sich durchaus sehen lassen:

JEP 339 – Edwards-Curve Digital Signature Algorithm (EdDSA)

Im Jahr 2007 wurden von Harold Edwards, seines Zeichens amerikanischer Mathematiker, Mathematikhistoriker und bis zu seinem Ruhestand Professor an der New York University, die sogenannten Edwards-Kurven vorgestellt. Diese elliptischen Kurven werden im Bereich der Elliptic Curve Cryptography eingesetzt. Der EdDSA ist nun ein modernes und performanteres Signaturschema, das deutliche Vorteile gegenüber dem im JDK implementierten Schema haben soll. Im RFC 8032 sind sämtliche Details zu dem Schema enthalten, das allerdings nicht das herkömmliche ECDSA (Elliptic Curve Digital Signature Algorithm) ersetzt.

Die neuen Services Signature, KeyFactory und KeyPairGenerator wurden für die Unterstützung von EdDSA dem SunEC-Provider hinzugefügt; neue Klassen und Interfaces sind entsprechend für die Repräsentation im API vorhanden. Wiederverwendet wird hingegen die Klasse NamedParameterSpec, die einst für XDH (JEP 324) entwickelt wurde, um EdDSA-Varianten und Kurvendomänenparameter zu beschreiben. Für Edwards-Kurvenpunkte, EdDSA-Schlüssel und Signaturparameter wurden neue Klassen und Interfaces entwickelt.
Für die Nutzung des APIs gibt JEP 339 folgendes Beispiel:

// example: generate a key pair and sign
KeyPairGenerator kpg = KeyPairGenerator.getInstance("Ed25519");
KeyPair kp = kpg.generateKeyPair();
// algorithm is pure Ed25519
Signature sig = Signature.getInstance("Ed25519");
sig.initSign(kp.getPrivate());
sig.update(msg);
byte[] s = sig.sign();

// example: use KeyFactory to contruct a public key
KeyFactory kf = KeyFactory.getInstance("EdDSA");
boolean xOdd = ...
BigInteger y = ...
NamedParameterSpec paramSpec = new NamedParameterSpec("Ed25519");
EdECPublicKeySpec pubSpec = new EdECPublicKeySpec(paramSpec, new EdPoint(xOdd, y));
PublicKey pubKey = kf.generatePublic(pubSpec);

JEP 360 – Sealed Classes (Preview)

Aus Projekt Amber kommen Sealed Classes als Preview Feature ins JDK. „Versiegelte Klassen“, also Sealed Classes, haben eine stark eingeschränkte Subclassing-Fähigkeit, die in der entsprechenden Klassen-Deklaration definiert wird. Zunächst wird der Deklaration der Modifikator sealed hinzugefügt, um das Feature zu aktivieren. Anschließend wird via permits-Klausel spezifiziert, welche Klassen die versiegelte Klasse erweitern dürfen:

package com.example.geometry;

public sealed class Shape
    permits Circle, Rectangle, Square {...}

Dies funktioniert übrigens auch mit abstrakten Klassen oder Interfaces. Besonders gut sollen die Sealed Classes mit den ebenfalls in JDK 15 als „Second Preview“ enthaltenen Records zusammenspielen.

JEP 371 – Hidden Classes

Mit JEP 371 werden „versteckte Klassen“ im JDK verfügbar, die die Arbeit mit Frameworks verbessern sollen. In Java 15 können so dynamisch erstellte Klassen stellenweise durch versteckte Klassen ersetzt werden.

Java-Entwickler, die mit Frameworks arbeiten, kennen das: Manche Klassen, die zur Laufzeit dynamisch erstellt werden, sind deutlich sichtbarer oder langlebiger, als es eigentlich nötig ist. Das liegt daran, dass die APIs zum Erstellen von Klassen, ClassLoader::defineClass und Lookup::defineClass, keinen Unterschied dabei machen, ob der Bytecode der Klasse zur Laufzeit dynamisch oder statisch beim Kompilieren erstellt wurde. Da die Klasse per se als „sichtbar“ definiert ist, wird sie entsprechend auch genutzt.

Durch „versteckte“ Klassen werden einige Use Cases abgedeckt, die nicht so einfach von anderen Klassen aufgerufen werden können. JEP 371 nennt einige solcher möglichen Einsatzgebiete beispielhaft: So kann etwa java.lang.reflect.Proxy versteckte Klassen definieren, die als Proxy-Klassen agieren. Diese werden – wie der Name bereits sagt – Proxy-Schnittstellen implementieren. Auch in Verbindung mit java.lang.invoke-StringConcatFactory kann man versteckte Klassen einsetzen, etwa um die Methoden für die konstanten Verkettungen zu enthalten. Für die Zusammenarbeit mit JavaScript in Java ist das Erstellen versteckter Klassen durch eine entsprechenden Engine möglich, die den Bytecode enthalten, der aus JavaScript-Anwendungen übersetzt wurde.

Einher mit der neuen Funktionalität geht allerdings auch das Bestreben, die Sprache selbst nicht zu ändern. Zudem ist es definitiv nicht das Ziel, die gesamte Funktionalität von sun.misc.Unsafe::defineAnonymousClass zu unterstützen. Für das API könnte sich dies, im Gegenteil, als fatal erweisen: Mandy Chung schlägt nämlich vor, es als „deprecated“ zu markieren und in einem der nächsten Java-Updates auszubauen.

JEP 372 – Remove the Nashorn JavaScript Engine

Auf der Jagd nach dem heiligen Gra(a)l gab es so manchen Schwund. Ein solcher ist die JavaScript-Engine Nashorn, wie in JEP 372 – Remove the Nashorn JavaScript Engine von Jim Laskey nachzulesen ist. Bereits 2018 wurde der Grundstein für den Ausbau der Nashorn-Engine, der entsprechenden APIs und der JJS Tools gelegt, in Java 11 wurden sie als deprecated markiert. Damit hatte die ursprünglich in JDK 8 via JEP 174 eingeführte Script-Engine keine besonders lange Halbwertszeit, auch wenn sie damals die eher antiquierte Rhino-Engine ersetzte.

Der Teufel liegt bei der Intention, das Nashorn loszuwerden, natürlich in der Zeit: JavaScript und der ECMA-Standard entwickeln sich rapide weiter und die Engine im JDK auf Stand zu halten ist gelinde gesagt herausfordernd, wie das Nashorn-Team im JEP schreibt. Da sich wohl auch die breitere Community nicht wirklich bewegt hat, um das Nashorn zu pflegen, bleibt nun nur der Schritt nach vorne, also die JavaScript-Engine in den verdienten Ruhestand zu schicken. Keinen Einfluss hat dieses JEP übrigens auf das API javax.script, dieses bleibt unverändert.

Entfernt wurden allerdings die Module jdk.scripting.nashorn und jdk.scripting.nashorn.shell, wie Jim Laskey schreibt. Ersteres enthält die Packages jdk.nashorn.api.scripting und jdk.nashorn.api.tree, Letzteres die JJS Tools.

JEP 373 – Reimplement the Legacy DatagramSocket API

Die Überarbeitung des DatagramSocket APIs war Bestreben des JEP 373. In diesem wurde vorgeschlagen, das API im Hinblick auf Aktualität und Wartbarkeit auf Vordermann zu bringen – ohne dabei die Rückwärtskompatibilität aus den Augen zu verlieren.

Via JEP 353 wurde bereits damit begonnen, veraltete Java-Schnittstellen zu überarbeiten und neu zu implementieren. Während es allerdings in JEP 353 um das Socket API ging (java.net.Socket und java.net.ServerSocket), wurde mit JEP 373 die Funktionalität des DatagramSocket APIs (java.net.DatagramSocket und java.net.MulticastSocket) aktualisiert. Wie auch beim Socket API geht es dabei vor allem um eine modernere und simplere Lösung, die leichter zu warten und debuggen ist. Auch diese Bemühungen wurden unter dem Schirm des Project Loom unternommen.

Ein großes Problem – wie dies auch bereits bei JEP 353 der Fall war – stellt die Tatsache dar, dass die Implementierungen der APIs java.net.DatagramSocket und java.net.MulticastSocket bereits seit JDK 1.0 Teil von Java und eine Mixtur aus veraltetem Java- und C-Code sind. Laut JEP 373 war besonders die Implementierung des MulticastSocket problematisch, da es aus einer Zeit vor IPv6 stammt. Davon abgesehen gibt es auch in Sachen Nebenläufigkeit etliche Stellschrauben, an denen gedreht wurde, was eine Überarbeitung und Neu-Implementierung nötig machte.

Anders als bei JEP 353 wurde allerdings nicht in Betracht gezogen, einfach einen Ersatz für DatagramSocketImpl bereitzustellen. Stattdessen wrapped DatagramSocket intern eine neue Instanz seiner selbst und sämtliche Aufrufe werden direkt an diese delegiert. Die so gewrappte Instanz ist entweder die neue Implementierung (ein Socket-Adapter der aus einem NIO-basierten DatagramChannel::socket erstellt wurde) oder ein Klon der veralteten DatagramSocket-Klasse, die dann an die veraltete Implementierung DatagramSocketImpl delegiert. Wie genau das funktionieren soll, zeigt das folgende Diagramm.

DatagramSocket

Quelle: Oracle

Man hat sich in Bezug auf den DatagramSocket entschieden, nicht gleich Nägel mit Köpfen zu machen: Im JEP 373 heißt es zwar, dass die veralteten Implementierungen wohl in einem der kommenden Releases als deprecated markiert und schließlich in mittelfristiger Zukunft entfernt werden sollen, aber vorerst gibt es sowohl die neue (NIO-basierte) und die herkömmliche Implementierung. Standardmäßig sollte aber die neue Implementierung aktiviert sein.

JEP 374 – Disable and Deprecate Biased Locking

Komplexität und eine immer geringer werdende messbare Verbesserung der Performance: Diese beiden Faktoren haben für die Schaffung von JEP 374 gesorgt. Biased Locking wird mit Java 15 standardmäßig deaktiviert und schließlich in einem späteren Release komplett ausgebaut.

Nutzer der HotSpot VM werden sich mit dem Begriff des Biased Locking bereits einmal auseinandergesetzt haben. Via Biased Locking soll das Ausführen einer vergleichenden und austauschenden atomaren Operation beim Erlangen eines Monitors verhindern. Dies geschieht dadurch, dass angenommen wird, dass ein Monitor im Besitz eines Threads bleibt, bis ein anderer Thread versucht den Monitor zu erhalten. Der Monitor bleibt somit einem bestimmten Thread zugeordnet („biased“) – dies sorgte in der Vergangenheit für Performance-Verbesserungen.

Und genau da kommen wir zum Knackpunkt von JEP 374: Die oben genannten Verbesserungen in Sachen Performance sind heute, gerade mit dem Aufkommen moderner Prozessorarchitekturen, nicht mehr so signifikant wie noch vor einigen Jahren. Damit ist gemeint, dass atomare Operationen heute sehr viel weniger ins Gewicht schlagen, als dies in der Vergangenheit der Fall war. Hinzu kommt, dass neuere Anwendungen ohnehin auf andere Technologien setzen.

Ein weiterer Faktor, der für das Ende von Biased Locking spricht, ist die Komplexität: Manchem Entwickler fällt es mitunter schwer, den Code des Ganzen zu durchblicken. Kein Wunder also, dass auch Änderungen im Subsystem für die Synchronisation schwerfallen. Die Lösung, vorgeschlagen von Patricio Chilano Mateo ist radikal: Biased Locking ist im JDK 15 standardmäßig ausgeschaltet, außer man nutzt in der Kommandozeile den Befehl -XX:+UseBiasedLocking. Die Funktion ist zudem als deprecated markiert worden und soll in einem späteren Release dann endgültig entfernt werden.

JEP 375 – Pattern Matching for instanceof (Second Preview)

JEP 375 führt konsequent weiter, was mit JEP 305 bereits begonnen wurde: Die Einführung des Pattern Matching für Java.

Im Zuge des Projektes Amber wird unter anderem am sogenannten Pattern Matching für Java gearbeitet. Für den Operator instanceof wird das Pattern Matching in Java 15 Wirklichkeit werden. Durch Pattern Matching soll, so führt Brian Goetz in JEP 305 – Pattern Matching for „instanceof“ (Preview) aus, die Programmiersprache Java prägnanter und sicherer werden.

Ein sogenanntes Pattern ist im Grunde nichts anderes als eine Kombination eines Prädikats für eine bestimmte Zielstruktur und einer Reihe von dazu passenden Variablen. Gibt es bei der Ausführung der Anwendung Treffer für die Variablen, werden ihnen passende Inhalte zugewiesen. Die „Form“ von Objekten kann so präzise definiert werden, woraufhin diese dann von Statements und Expressions gegen den eigenen Input getestet werden.

Wurde in JEP 305 nur eine Art von Pattern vorgeschlagen (Type Test Pattern), hat die zweite Preview, die als JEP 375 – Pattern Matching for „instanceof“ (Second Preview) für JDK 15 vorgeschlagen wurde, noch das Deconstruction Pattern an Bord. Das Type Test Pattern besteht aus dem oben genannten Prädikat, das einen Typen spezifiziert, und einer einzelnen bindenden Variable. Das Deconstruction Pattern besteht aus einem Prädikat, das einen Record-Typ spezifiziert, und mehreren bindenden Variablen für die Komponenten des Record-Typs.

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 könnte dann Pattern Matching für weitere Sprachkonstrukte wie Switch Expressions kommen.

JEP 377 – ZGC: A Scalable Low-Latency Garbage Collector (Production)

Mit diesem JEP wird vorgeschlagen, den Z Gargabe Collector aus dem experimentellen Status zu entheben und ihn zu einem festen Bestandteil des JDKs zu machen. Dabei soll der Standard allerdings nicht verändert werden: der G1 Garbage Collector bleibt auch weiterhin der standardmäßig genutzte GC in Java 15. Der ZGC ist bereits seit Java 11 Bestandteil des JDKs und wurde mit JEP 333 in das System eingeführt. Nach etlichen Tests und Bugfixes soll er nun bereit für die Produktion sein.

JEP 378 – Text Blocks (Standard)

In Java 13 war JEP 355 als Preview-Feature enthalten, mit dem der neue Typ Text Block eingeführt werden sollte. Die Bemühungen des JEPs basierten auf den Grundlagen, die bereits für JEP 326 und die Raw String Literals geschaffen wurden. Die im Vorschlag beschriebenen Textblöcke sollen mehrzeilige String-Literale darstellen. Ihre Formatierung unterliegt einheitlichen Regeln und orientiert sich an der Darstellung des Texts im Quellcode, sodass Entwickler nicht zwingend auf Befehle zurückgreifen müssen, um das Layout des Texts zu beeinflussen. Den kompletten Style Guide zu Text Blocks haben Jim Laskey und Stuart Marks verfasst und er ist auf JAXenter zu finden, In seinem Artikel „Textblöcke in Java 13: Warum sich das lange Warten gelohnt hat“ geht Tim Zöller auf das Feature genauer ein.

Lesen Sie auch: Java Tutorial: Eine Einführung in Text Blocks und offizieller Style Guide

Zu den Zielen, die mit der Einführung von Text Blocks verbunden werden, gehört unter anderem das leichtere Gestalten mehrzeiliger Strings für Programmierer. Durch die Regeln zur automatischen Formatierung wären bei einer Einführung des Typs keine Escape-Sequenzen im Stil von \n nötig. Insbesondere solche Java-Programme, die Code anderer Programmiersprachen innerhalb von Strings enthalten, sollen mit dem neuen Format besser lesbar werden. JEP 368, enthalten in Java 14, brachte, basierend auf Nutzer-Feedback, zwei neue Escape-Sequenzen für dieses Feature, die eine feingranulare Kontrolle der Verarbeitung von Newlines und Whitespaces erlauben: \<line-terminator> und \s. Erstere Escape-Sequenz kann genutzt werden, um einen Umbruch für sehr lange String-Literale zu forcieren, ohne diese in kleinere „Substrings“ aufzuteilen.

Nun folgt mit JEP 378: Text Blocks (Standard) die offizielle Einführung als Standard in Java 15. Technisch sieht das Feature wie folgt aus:

Ohne \<line-terminator> Escape-Sequenz:

String literal = "Lorem ipsum dolor sit amet, consectetur adipiscing " +
                 "elit, sed do eiusmod tempor incididunt ut labore " +
                 "et dolore magna aliqua.";

Mit \<line-terminator> Escape-Sequenz:

String text = """
                Lorem ipsum dolor sit amet, consectetur adipiscing \
                elit, sed do eiusmod tempor incididunt ut labore \
                et dolore magna aliqua.\
                """;

Die Escape-Sequenz \s lässt sich einfach als einzelnes Leerzeichen (\u0020) beschreiben. Damit lässt sich im unteren Beispiel sicherstellen, dass die Zeilen exakt 6 Stellen haben und nicht länger sind:

String colors = """
    red  \s
    green\s
    blue \s
    """;

Diese Escape-Sequenz kann in den neuen Text Blocks, aber auch in klassischen String-Literalen genutzt werden.

JEP 379 – Shenandoah: A Low-Pause-Time Garbage Collector (Production)

Wie JEP 377 geht es in JEP 379 ebenfalls um einen Garbage Collector, in diesem Fall den Shenandoah GC. Auch dieser soll endlich den experimentellen Status verlassen und fester Bestandteil von Java 15 werden – und wie ZGC soll auch Shenandoah nicht den Standard Garbage Collector von Java ersetzt. Bereits 2014 wurde mit JEP 189 der Shenandoah GC als experimentelles Feature für Java vorgeschlagen, doch erst mit JDK 12 wurde er tatsächlich in Java integriert.

JEP 381 – Remove the Solaris and SPARC Ports

Das Betriebssystem Solaris stammt noch aus den Beständen von Sun Microsystems und ist mittlerweile nicht mehr wirklich zeitgemäß. Entsprechend wenig überraschend war daher der Wunsch von Oracle, die Ports für Solaris/SPARC, Solaris/x64 und Linux/SPARC mit JEP 362 als deprecated zu markieren. Der nächste Schritt, sie endgültig loszuwerden, ist nun mit JEP 381 im JDK 15 gekommen. Es sei allerdings angemerkt, dass alte Java-Versionen (bis einschließlich JDK 14) auf alten Systemen allerdings unverändert laufen sollen, inklusive der entsprechenden Ports.

Ziel des Ganzen ist es, sich um andere Features kümmern zu können. Sollte sich allerdings doch eine Gruppe engagierter und interessierter Entwickler finden, die die Ports betreuen und verwalten wollen, könnte die Entfernung aus dem JDK allerdings auch zu einem späteren Zeitpunkt noch gekippt werden.

JEP 383 – Foreign-Memory Access API (Second Incubator)

Es gibt tonnenweise Java-Bibliotheken und auch -Anwendungen, die auf fremden Speicher zugreifen. Prominente Beispiele sind Ignite, mapDB, memchaced oder Nettys ByteBuf API. Dennoch stellt das Java API selbst keine gute Möglichkeit hierfür zur Verfügung – und das obwohl dadurch Kosten in Sachen Garbage Collection (besonders bei der Verwaltung großen Caches) gespart und Speicher über mehrere Prozesse hinweg geteilt werden kann. Auch das Serialisieren und Deserialisieren von Speicherinhalten via Mappings von Dateien in den Speichern wird durch den Zugriff auf fremden Speicher möglich (etwa via mmap).

Mit JEP 370 wurde ein passendes Java API ins JDK implementiert, mit dem Java-Anwendungen sicher und effizient auf fremden Speicher zugreifen lässt, der außerhalb des Java Heaps angesiedelt ist. Wichtig sind die drei Prämissen: Allgemeingültigkeit, Sicherheit und Determinismus. JEP 383 stellt die zweite Inkubatorphase des im Projekt Panama entwickelten APIs dar.

Lesen Sie auch: 25 Jahre Java: Eine Programmiersprache zelebriert ihr Jubiläum

In diesem Zusammenhang bedeutet „Allgemeingültigkeit“, dass ein einziges API in Verbindung mit unterschiedlichen fremden Speichern arbeiten sollte (gemeint sind nativer Speicher, persistenter Speicher etc.). Die „Sicherheit“ der JVM ist das höchste Gut, daher sollte das API nicht dazu fähig sein, diese zu unterwandern – völlig egal, welcher Speicher zum Einsatz kommt. Zudem („Determinismus“) sollte die Freigabe von Speicher explizit im Quelltext erfolgen.

Für den Rehaul in Java 15 wurde das neue VarHandle combinator API implementiert, das die Individualisierbarkeit der var-Handles für den Speicherzugriff gewährleistet. Die Unterstützung für das Parallel Processing einzelner Speichersegmente via Spliterator-Interface ist ebenso Teil der Überarbeitung wie ein verbesserter Support für „gemappte“ Speichersegmente (bspw. MappedMemorySegment::force). Neu sind auch sichere API-Punkte, um serielle Einschränkungen zu unterstützen, und unsichere API-Punkte. Letztere erlauben das Manipulieren und Rückverweisen von Adressen, die etwa von nativen Aufrufen stammen. Durch unsichere API-Punkte können zudem solcherlei Adressen in synthetische Speichersegmente gewrappt werden.

JEP 383 wurde im Zuge des Project Panama entwickelt und stellt eine klare Alternative zur Verwendung von existierenden APIs wie ByteBuffer, Unsafe oder JNI dar. Natürlich hilft die Implementierung bei der Erreichung der generellen Maxime des Projektes: der Unterstützung von nativer Interoperabilität von Java.

JEP 384 – Records (Second Preview)

JEP 384 bringt Records als „Second Preview“ für Java. Bei Records handelt es sich um einen neuen Klassentyp, der im Zuge des Projektes Valhalla entwickelt wurde. Diese stellen – wie beispielsweise auch enums – eine eingeschränkte Form der Deklaration class dar. Records unterscheiden sich von klassischen Klassen darin, dass sie ihr API nicht von dessen Repräsentation entkoppeln können. Die Freiheit die dabei verloren geht, wird aber durch die gewonnene Präzision wettgemacht.
Im Proposal zu den Records hieß es dazu, dass ein Record „der Zustand, der gesamte Zustand und nichts als der Zustand“ sei. Er besteht aus einem Namen, einem Header und dem Body:

record Point(int x, int y) { }

Der Header stellt hier die Liste der Komponenten des Records dar, also die Variablen, die den Zustand beschreiben. Records bleiben dabei Klassen, auch wenn sie eingeschränkt sind. So können sie etwa Annotationen oder Javadocs enthalten und deren Body u.a. statische Felder sowie Methoden, Konstruktoren oder Instanzmethoden deklarieren. Was sie allerdings nicht vermögen, ist die Erweiterung anderer Klassen oder die Deklaration von Instanzfeldern (mit der Ausnahme der Statuskomponenten, die im Header des Records deklariert wurden).

JEP 385 – Deprecate RMI Activation for Removal

Den Abschluss für JDK 15 bildet erneut eine Schlankheitskur: Der RMI-Activation-Mechanismus wird in den Ruhestand geschickt und als deprecated markiert. Dieser ist dafür verantwortlich, dass RMI-basierte Services sogenannte Stubs exportieren können, deren Gültigkeit die Lebenszeit eines Remote-Objektes oder der JVM, die es enthält, übersteigt. Die Krux an der Geschichte ist, dass mit „konventionellem“ RMI Stubs sofort nach der Zerstörung eines Remote-Objektes ungültig werden. Für Entwickler bedeutet es gehörigen Aufwand, diesen Zustand via komplexer Fehlerbehandlungslogik aufzulösen. Hierbei kann der RMI-Activation-Service helfen. Allerdings wird der Mechanismus verhältnismäßig selten genutzt, weshalb mit JEP 385 das Ende eingeläutet wird.

Weitere Informationen zu Java 15 und den entsprechenden JEPs gibt es einerseits auf der Seite für das JDK und in den einzelnen JEPs. Herunterladen kann man die Standard Edition von Java 15 auf der offiziellen Downloadseite von Oracle.

Geschrieben von
Dominik Mohilo
Dominik Mohilo
Dominik Mohilo studierte Germanistik und Soziologie an der Goethe-Universität in Frankfurt. Seit 2015 ist er Redakteur bei S&S-Media.
Kommentare

Hinterlasse einen Kommentar

avatar
4000
  Subscribe  
Benachrichtige mich zu: