© Excellent backgrounds/Shutterstock.com
Java Magazin
Interview mit Uwe Schindler

„Es geht auch ohne sun.misc.Unsafe - mit Sicherheit!“

Das von vielen Libraries und Frameworks genutzte sun.misc.Unsafe-API soll per Default aus Java 9 entfernt werden. Wir haben Lucene-Entwickler Uwe Schindler nach seiner Meinung zu dieser kontrovers diskutierten Entscheidung befragt.

Uwe Schindler


Java Magazin: Es gibt derzeit eine Debatte um die mögliche Entfernung von sun.misc.Unsafe aus Java 9. Zunächst einmal: Was ist sun.misc.Unsafe eigentlich genau? Uwe Schindler: Unsafe ist eine interne Klasse des Oracle JDK/OpenJDK. Sie wird eigentlich nur hinter den Kulissen von zahlreichen öffentlichen Java-APIs benutzt, um spezielle Operationen durchzuführen, welche sonst nativen C- oder Assembler-Code benötigen würden. Dazu gehören grob folgende Teile:Atomare Compare-and-Swap-Operationen: Hierfür gibt es im Java-Bytecode keine native Entsprechung, daher werden diese Dinge von den Klassen in java.util.concurrent benutzt, um zum Beispiel AtomicInteger, LongAdder oder ConcurrentHashMap zu implementieren.Volatile Array-Zugriffe: Auch hierfür gibt es keinen Java-Bytecode: Man kann nur das ganze Array, aber nicht die Elemente „volatil“ deklarieren.Direkter Zugriff auf Off-Heap-Memory: Es gibt hier quasi ein malloc() – wie aus C bekannt – und dann Methoden für den Zugriff auf den so allozierten Speicher. Diese Funktionalität wird größtenteils von Direct Buffers aus dem NIO-API benutzt, sowie zur Implementierung von Memory-mapped-Dateien.Einige nützliche Konstanten zum internen Aufbau der Objektinstanzen von Java. Diese Konstanten werden normalerweise für den Aufruf der vorher beschriebenen Methoden benötigt; sie können aber auch gut dafür eingesetzt werden, um den Platzbedarf im Heap-Speicher von Objektinstanzen zur Laufzeit zu schätzen.Schindler: Das Problem mit Unsafe ist ganz einfach: Die Methoden darin können auf den Speicher im und außerhalb des Heaps direkt über absolute Pointer zugreifen, man könnte das also dazu benutzen, um die JVM zu crashen (SIGSEGV), oder gar nativen Maschinen-Assembler-Code in die JVM injizieren. Daher muss man das als „unsicher“ ansehen (daher auch der Name). Normaler in Java geschriebener Code sollte daher die „offiziellen“ APIs benutzen: AtomicInteger, ConcurrentHashMap, ByteBuffer etc. Das JDK verhindert eigentlich offiziell die Benutzung von sun.misc.Unsafe, indem dessen statische Factory getUnsafe() caller-sensitiv gemacht wird: Man kann diese Methode nur aus dem JDK-Code selbst aufrufen, nicht jedoch aus Applikationscode. Findige Entwickler haben jedoch via Java-Reflection trotzdem die Möglichkeit gefunden, auf eine Instanz von Unsafe zuzugreifen (sofern kein SecurityManager dies verbietet).Und genau hier setzt Java 9 an: sun.misc.Unsafe wird als Folge des neuen Modulkonzepts aus dem Modul java.base entfernt und in ein in...

Java Magazin
Interview mit Uwe Schindler

„Es geht auch ohne sun.misc.Unsafe - mit Sicherheit!“

Das von vielen Libraries und Frameworks genutzte sun.misc.Unsafe-API soll per Default aus Java 9 entfernt werden. Wir haben Lucene-Entwickler Uwe Schindler nach seiner Meinung zu dieser kontrovers diskutierten Entscheidung befragt.

Uwe Schindler


Java Magazin: Es gibt derzeit eine Debatte um die mögliche Entfernung von sun.misc.Unsafe aus Java 9. Zunächst einmal: Was ist sun.misc.Unsafe eigentlich genau? Uwe Schindler: Unsafe ist eine interne Klasse des Oracle JDK/OpenJDK. Sie wird eigentlich nur hinter den Kulissen von zahlreichen öffentlichen Java-APIs benutzt, um spezielle Operationen durchzuführen, welche sonst nativen C- oder Assembler-Code benötigen würden. Dazu gehören grob folgende Teile:Atomare Compare-and-Swap-Operationen: Hierfür gibt es im Java-Bytecode keine native Entsprechung, daher werden diese Dinge von den Klassen in java.util.concurrent benutzt, um zum Beispiel AtomicInteger, LongAdder oder ConcurrentHashMap zu implementieren.Volatile Array-Zugriffe: Auch hierfür gibt es keinen Java-Bytecode: Man kann nur das ganze Array, aber nicht die Elemente „volatil“ deklarieren.Direkter Zugriff auf Off-Heap-Memory: Es gibt hier quasi ein malloc() – wie aus C bekannt – und dann Methoden für den Zugriff auf den so allozierten Speicher. Diese Funktionalität wird größtenteils von Direct Buffers aus dem NIO-API benutzt, sowie zur Implementierung von Memory-mapped-Dateien.Einige nützliche Konstanten zum internen Aufbau der Objektinstanzen von Java. Diese Konstanten werden normalerweise für den Aufruf der vorher beschriebenen Methoden benötigt; sie können aber auch gut dafür eingesetzt werden, um den Platzbedarf im Heap-Speicher von Objektinstanzen zur Laufzeit zu schätzen.Schindler: Das Problem mit Unsafe ist ganz einfach: Die Methoden darin können auf den Speicher im und außerhalb des Heaps direkt über absolute Pointer zugreifen, man könnte das also dazu benutzen, um die JVM zu crashen (SIGSEGV), oder gar nativen Maschinen-Assembler-Code in die JVM injizieren. Daher muss man das als „unsicher“ ansehen (daher auch der Name). Normaler in Java geschriebener Code sollte daher die „offiziellen“ APIs benutzen: AtomicInteger, ConcurrentHashMap, ByteBuffer etc. Das JDK verhindert eigentlich offiziell die Benutzung von sun.misc.Unsafe, indem dessen statische Factory getUnsafe() caller-sensitiv gemacht wird: Man kann diese Methode nur aus dem JDK-Code selbst aufrufen, nicht jedoch aus Applikationscode. Findige Entwickler haben jedoch via Java-Reflection trotzdem die Möglichkeit gefunden, auf eine Instanz von Unsafe zuzugreifen (sofern kein SecurityManager dies verbietet).Und genau hier setzt Java 9 an: sun.misc.Unsafe wird als Folge des neuen Modulkonzepts aus dem Modul java.base entfernt und in ein in...

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