© Excellent backgrounds/Shutterstock.com
Java Magazin
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.

Angelika Langer, Klaus Kreft


Java 9 – ÜberblickTeil 1: Ergänzungen der Sprache und der existierenden APIsTeil 2: JVM Internals Teil 3: Neue und alte JDK-Tools Teil 4: Project Jigsaw aka Java Module System Teil 5: JDK-interne Packages wie sun.misc.* und ihr Ersatz Teil 6: Concurrency Updates

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...

Java Magazin
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.

Angelika Langer, Klaus Kreft


Java 9 – ÜberblickTeil 1: Ergänzungen der Sprache und der existierenden APIsTeil 2: JVM Internals Teil 3: Neue und alte JDK-Tools Teil 4: Project Jigsaw aka Java Module System Teil 5: JDK-interne Packages wie sun.misc.* und ihr Ersatz Teil 6: Concurrency Updates

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...

Neugierig geworden?


    
Loading...

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