© Excellent backgrounds/Shutterstock.com
Teil 5: JDK-interne-Packages wie sun.misc.* und ihr Ersatz

Unsicher wird unsicher


Wir wollen Ihnen in dieser Artikelreihe einen Überblick über die Neuerungen in Java 9 verschaffen und einige Features von Java 9 kurz erläutern. Dabei haben wir diejenigen Themen ausgewählt, von denen wir denken, dass sie für Java-Entwickler am interessantesten sind. Und natürlich werfen wir einen Blick auf die größte Neuerung: das Modulsystem.

Im Folgenden geht es um JDK-interne Low-Level-APIs, die üblicherweise in der Mainstreamprogrammierung eher nicht zum Einsatz kommen. Allerdings werden sie in vielen Bibliotheken und Frameworks benutzt, sodass sie den durchschnittlichen Java-Entwickler am Ende vielleicht beim Umstieg auf Java 9 doch indirekt betreffen könnten, weil die im Projekt benutzten Bibliotheken nicht mit Java 9 zurechtkommen. Worum geht es? Im JDK gibt es eine Reihe von Packages, die ausschließlich für interne Zwecke gedacht waren, nämlich für die Implementierung anderer JDK-Klassen. Dazu gehören viele der sun.*-Packages. Da es ohne das Modulkonzept keine Möglichkeit gab, sie wirksam vor dem Zugriff beliebiger Benutzer zu schützen, wurden Klassen wie sun.misc.Unsafe in zahlreichen Bibliotheken und Frameworks verwendet, obwohl sie dafür nicht gedacht waren. Diese internen APIs werden beginnend mit Java 9 allmählich verschwinden. Das bedeutet, dass sie entweder der allgemeinen Benutzung entzogen oder sogar komplett entfernt und durch neue APIs ersetzt werden.

Einige Klassen aus sun.misc gibt es schon im JDK 9 nicht mehr. Es betrifft die Klassen sun.misc.BASE64Encoder und sun.misc.BASE64Decoder. Man muss stattdessen die Klasse java.util.Base64 verwenden, die bereits im JDK 8 hinzugefügt wurde. Andere interne sun.*-Klassen existieren noch, sind aber in einem speziellen internen Modul mit dem Namen jdk.unsupported verlagert worden, um klarzumachen, dass man sie nach Möglichkeit nicht mehr benutzen, sondern sich nach Ersatz umsehen sollte. Das betrifft u. a. die Klassen sun.misc.Signal, sun.misc.SignalHandler, sun.misc.Unsafe und die Methoden getCallerClass() aus sun.reflect.Reflection und newConstructorForSerialization() aus sun.reflect.ReflectionFactory. Für eine Übergangszeit kann man die Schutzmechanismen des Modulkonzepts über die Aufrufoption --add-exports (für javac und java) aushebeln und die Klassen zumindest in Java 9 noch benutzen, aber langfristig muss man sie ersetzen.

Seit Java 8 gibt es schon das Tool jdeps, das Abhängigkeiten zwischen Packages und Klassen analysieren kann. Das Werkzeug ist als Unterstützung bei der Modularisierung von Applikationen gedacht, damit man die Abhängigkeiten erkennen und sie im Rahmen der Modularisierung entflechten kann. Das jdeps-Tool hat eine Option -jdkinternals, mit der man sich zeigen lassen kann, welche internen APIs verwendet werden. Man bekommt dann sofort den Hinweis, dass die internen APIs demnächst nicht mehr unterstützt werden und bekommt, falls vorhanden, Vorschläge, was man als Ersatz verwenden soll.

Insbesondere das Verschwinden der Klasse sun.misc.Unsafe hat Entsetzen und Protest hervorgerufen, weil die Benutzung ihrer Features über das JDK hinaus weit verbreitet ist. Zahlreiche Bibliotheken und Frameworks sind betroffen, z. B. Akka, Grails, Guava, Hadoop, Hibernate, JRuby, LMAX Disruptor, Netty, Scala und Spring, um nur einige zu nennen. Sie alle müssen für eine Übergangszeit die Schutzmechanismen des Modulkonzepts mithilfe der bereits erwähnten java- bzw. javac-Aufrufoption --add-exports aushebeln und langfristig die sun.misc.Unsafe-Features durch andere Mittel ersetzen.

Es gibt schon seit Java 8 eine Replacement-Tabelle für verschiedene interne APIs [1]. In der Tabelle ist aufgelistet, welche internen APIs durch welche anderen APIs zu ersetzen sind. Als Ersatz für die Methode getCallerClass() aus sun.reflect.Reflection kommt in Java 9 das S...

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