Suche
Interview mit Uwe Schindler

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

Hartmut Schlosser

Uwe Schindler

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.

JAXenter: 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 „volatile“ 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 allozierte Speicher. Diese Funktionalität wird größtenteils von Direct Buffers aus der 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.

JAXenter: Weshalb soll nun sun.misc.Unsafe entfernt werden?

Uwe Schindler: Das Problem mit Unsafe ist ganz einfach: Die Methoden darin können auf den Speicher im und außerhalb des Heap direkt über absolute Pointer zugreifen, man könnte das also dazu benutzen, um die JVM zu crashem (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-sensitive 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 internes Modul geschoben. Applikationscode kann weder auf Klassen aus diesen internen Modulen zugreifen noch diese instanzieren. sun.misc.Unsafe existiert also nicht mehr außerhalb des JDK, komplett abgeschottet durch das neue Modul-Konzept. Class.forName() wird daher eine ClassNotFoundException werfen. Das verhindert dann wirklich jeglichen Zugriff von Applikationscode!

JAXenter: Was würde ein Entfernen von sun.misc.Unsafe z.B. für Apache Lucene und Solr bedeuten?

Uwe Schindler: Dies würde keinerlei Einfluss auf Apache Lucene haben, denn wir haben bei uns Richtlinien, die solchen unsicheren Code verbieten. Wir sind eine Bibliothek, welche von sehr vielem Code benutzt wird, und wir können nicht einfach die Sicherheit des ganzen Programms gefährden. Wenn man sich den Code von Apache Lucene ansieht, werden viele Programmierer, welche Unsafe benutzt haben, vielleicht verstehen, dass es mit Sicherheit auch “ohne” geht!

Bei Apache Solr kann es eventuell zu Problemen kommen, weil es dort zahlreiche Drittanbieter-Libraries gibt, von denen wir nicht wissen, ob dort evtl. Unsafe benutzt wird. Eine davon haben wir aber vor kurzem ausgetauscht.

JAXenter: Kritiker befürchten, dass durch ein Entfernen von sun.misc.Unsafe zahlreiche Mainstream-Anwendungen nicht mehr funktionieren werden. Haben sie Recht?

Uwe Schindler: Das ist in der Tat eine wahre Aussage! Es gibt zahlreiche Libraries, u.a. Netty, welche intern ebenfalls Unsafe (über die Reflection-Hacks) benutzen. Viele Projekte benutzen auch teilweise einige javax-Libraries, welche erst in Java 8 hinzugefügte neue java.util.concurrent-Klassen bereitstellen (z.B. LongAdder), um diese auch in Java 6 oder Java 7 benutzen zu können. Hier sollte einfach auf Java 8 als Mindestanforderung upgedatet werden und diese (dann obsolete) externe Bibliothek entfernt werden.

JAXenter: Was hältst du von dem Vorschlag, Teile von sun.misc.Unsafe neu zu implementieren und offiziell ins JDK zu übernehmen?

Uwe Schindler: Es gibt in der Tat einige Teile von sun.misc.Unsafe, die nicht wirklich “unsicher” sind. So sind z.B. die ganzen Konstanten oder die compare-and-swap primitives durchaus sicher benutzbar, wenn diese ordentlich gekapselt werden. Direkter Zugriff auf absolute Speicheradressen (à la “C-Code”) sollte aber wirklich vermieden werden, das würde die ganze Sicherheit der Java-Plattform komplett aushöhlen! Wie man am Code von Apache Lucenes ByteBufferIndexInput sieht, kann man über die ByteBuffer.allocateDirect()-API problemlos auch Off-Heap-Speicher benutzen, allerdings mit einem kleinen Laufzeit-Overhead durch Sicherheitsprüfungen. Optimierungen in der Hotspot-VM haben aber in der Zwischenzeit die “Ängste” von Leuten, welche das letzte Quäntchen an Geschwindigkeit haben wollen, aber eigentlich obsolet gemacht! Davon sollte man sich langsam trennen.

Daher sollten die Entwickler dieser Libraries nachdenken und eventuell neue Updates zur Verfügung stellen, welche ohne Unsafe auskommen. Dazu sollte man bis zur Veröffentlichung von Java 9 sicher in der Lage sein! Es wird aber sicher einen kleinen “Gap” in der Entwicklung geben, wo es zu Problemen kommen kann. Daran haben die Java-9-Entwickler jedoch gedacht und einen “Kommandozeilen-Schalter” vorgestellt, welcher quasi “sun.misc.Unsafe” wieder für Legacy-Code sichtbar macht.

JAXenter: Vielen Dank für dieses Interview!

Uwe Schindler ist Mitglied des Project Management Committee im Apache-Lucene-Projekt. Er ist mit seiner Consulting-Firma SD DataSolutions GmbH in Bremen ansässig und kümmert sich am Zentrum für Marine Umweltwissenschaften (MARUM) um die Suche nach geowissenschaftlichen Daten in der Umweltdatenbank PANGAEA.
Blog: http://blog.thetaphi.de
Twitter: @ThetaPh1

Verwandte Themen:

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Content-Stratege, IT-Redakteur, Storyteller – als Online-Teamlead bei S&S Media ist Hartmut Schlosser immer auf der Suche nach der Geschichte hinter der News. SEO und KPIs isst er zum Frühstück. Satt machen ihn kreative Aktionen, die den Leser bewegen. @hschlosser
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: