Kolumne

Java 9 Release verschoben: Warum Jigsaw noch nicht fertig ist

Uwe Schindler

Am Dienstag, 1. Dezember 2015, hat Mark Reinhold auf der OpenJDK Mailingliste angekündigt, was viele schon vorhergesehen haben: Das Release von Java 9 wird wohl um sechs Monate nach hinten verschoben. Noch ist das ganze nicht offiziell – sollte aber nicht bis nächste Woche Widerspruch aus der Community eingehen, wird daran festgehalten [1].

Als Grund nennt Mark Reinhold, dass die Hauptänderung in Java 9, das Modulsystem Jigsaw, einfach noch nicht fertig sei. Doch wie kam es hierzu? Am Modulsystem wird schließlich schon seit Jahren gebastelt, und es war eigentlich auch schon für Java 8 angekündigt?

Jigsaw Status Quo

Zuerst lohnt es sich, auf den aktuellen Stand zu sehen: Der Feature-Freeze (der Zeitpunkt, zu dem keine neuen Features mehr für Java 9 angenommen werden) ist in etwa 2 Wochen, doch die gesamte Jigsaw-Modularisierung ist bis zum heutigen Zeitpunkt noch nicht in den Hauptentwicklungszweig übernommen worden. Wer das neue Modulsystem testen will, der darf derzeit nicht die offiziellen Java 9 Preview Builds runterladen [2], sondern muss explizit die “Jigsaw”-Variante auswählen. Warum das so ist, konnte der Autor bis heute nicht herausfinden.

Der Grund für diese unterschiedlichen Download-Lokationen liegt aber wohl auch darin, dass viele der populären Open-Source-Projekte teilweise überhaupt nicht mit der Jigsaw-Variante von Java 9 funktionieren, so beispielsweise bis vor kurzem auch die populäre JVM-Sprache Groovy. Wie ja schon in den früheren Diskussionen um das strittige sun.misc.Unsafe [3], sind die Gründe für diese Probleme ähnlich: Durch das Modulsystem wird ein weiterer – sehr begrüßenswerter – Sicherheitsmantel um das JDK gelegt.

Früher war es einfach, mal schnell versteckte Klassen und Methoden im JDK via Reflection sichtbar zu machen (sofern die entsprechenden Rechte durch das Java-Sicherheitssystem gewährt wurden, was für viele serverseitige Anwendungen meist der Fall war). Der Aufruf dieser Methode setAccessible() zur Sichtbarmachung privater Methoden und Klassen wird in Java 9 mit einer neuen InaccessibleObjectException bestraft, außer der betreffende Code liegt auf einer Whitelist (wozu auch das umstrittene sun.misc.Unsafe gehört). Da gibt es nun (endlich) keinen Weg mehr drumherum; Java 9 verbietet das zum jetzigen Zeitpunkt – mit und ohne SecurityManager. Der Grund für dieses Verhalten ist, dass diese Methoden oftmals mit privaten, nicht öffentlichen Interfaces arbeiten, welche durch den Aufruf von setAccessible im Umkehrschluss im Modulsystem öffentlich sein müssten. Sucht man dazu auf GitHub nach typischen Programmierpattern wie das allseits bekannte setAccessible(), sieht man jetzt schon, welcher Code nicht mehr unter Java 9 funktionieren wird. Und das ist leider enorm viel Code, auch in bekannten Bibliotheken.

Lucene, Solr, Elasticsearch

Die Entwickler von Apache Lucene, Apache Solr und Elasticsearch haben in den aktuellen Releases hier schon Abhilfe geschaffen und jegliche Benutzung von setAccessible im Sourcecode schlicht verboten! Wenn man sich nächer mit dem Problem beschäftigt, stellt man schnell fest, dass dies oftmals nicht wirklich nötig ist. Das einzige, was in Apache Lucene noch geblieben ist, ist der Zugriff auf sun.misc.Cleaner in MMapDirectory; aber dies steht auf der Whitelist von Java 9, weil es ein bekanntes Problem ist. Aber dieses ist genau eines der Probleme, welche vielleicht bis zum endgültigen Release von Java 9 noch behoben werden könnten, wenn mehr Zeit gewährt wird. Es ist daher anzunehmen, dass das Jigsaw-Team auch noch Zeit benötigt, Ungereimtheiten zu beseitigen, um zumindest die meisten der vielfach benutzen Softwarekomponenten und -Bibliotheken noch kompatibel zu machen.

Modul-Dateiformate

Forscht man etwas weiter, stellt man auch fest, dass es noch zahlreiche weitere offene Issues um Jigsaw herum gibt, so dass das Modulsystem für Tests durch die breite Öffentlichkeit noch nicht bereit ist. Ein Punkt ist derzeit, dass das Dateiformat für die Module noch nicht fest entschieden ist und auf den Mailinglisten noch heftig diskutiert wird. Was die Sache noch etwas verwirrender macht, ist die Tatsache, dass es derzeit zwei Formate gibt, JIMAGE und JMOD. Ersteres ist ein vollkommen neues Format mit schnellem Zugriff auf die darin enthaltenen Klassen ohne das für ZIP-Dateien übliche und langsame Durchsuchen des ZIP-Entry-Listings. Dieses neue Format wird innerhalb des JDK benutzt, um das Laden von Klassen deutlich zu beschleunigen. Aber es gibt auch noch das neue Jigsaw-JMOD-Format, welches genau wie das JAR-Format auf dem ZIP-Format beruht, aber zusätzlich neben modulspezifischen Metadaten auch plattformspezifische Bibliotheken wie DLL oder SO-Dateien enthalten kann. Die Jigsaw-Builds liefern derzeit alle Module in beiden Formaten aus, während die regulären Java 9 Builds nur das schnelle JIMAGE-Fomat benutzen. Wie das ganze Layout der JDK-Installation am Ende dann aussehen wird, ist jetzt noch nicht absehbar [4]. Das JMOD-Format soll aber zukünftig der Ersatz für das JAR-Format werden, womit man ganze Java-Anwendungen als Modul ausliefern kann, welches dann alle Metadaten über Abhängigkeiten und exportierte APIs enthält. Damit wird es dann darüberhinaus möglich sein, auch mit der Anwendung eine abgespeckte JRE ausliefern zu können, welche nur noch benötigte Module enthält.

Durch die Verzögerungen in der Entwicklung erscheint eine Verschiebung des Release-Datums auch aus einem weiteren Grund sinnvoll zu sein: Das neue Java-9-Modulsystem muss pünktlich zum Release auch in den bestehenden Entwicklungsumgebungen wie Eclipse benutzbar sein. Da hier alles noch sehr im Umbruch ist, sollte natürlich auch den Tool-Entwicklern genügend Zeit gegeben werden! Auf der OpenJDK-Jigsaw-Mailingliste sieht man häufig Diskussionen, wie man mit Apache Maven neue Module selbst bauen kann. Die Entwicklergemeinde ist auch schon schwer damit beschäftigt, die passenden Maven-Mojos für das JMOD-Packaging zur Verfügung zu stellen. Auch das letzte Gradle-Release (2.9) [5] hat schon die Infrastruktur für Java-9-Module eingebaut, obwohl allerdings derzeit noch nicht benutzbar.

Mehr Zeit für Java 9 – mehr Zeit für neue Features

Insgesamt ist bei zahlreichen Projekten auch schon erkennbar, dass die Codebasis auf Java 9 vorbereitet wird. In Apache Lucene ist in der wohl in den kommenden Wochen herauskommenden Version 5.4 schon mit voller Jigsaw-Unterstützung zu rechnen. Auch Elasticsearch läuft schon jetzt problemlos mit dem Modulsystem. Dabei kommt Apache Lucene nun mit minimalen Runtime-Permissions aus und läuft daher problemlos unter Java 9.

Als Mitglied des Apache-Lucene-Teams freue ich mich schon jetzt auf die durch die Verlängerung der Entwicklungszeit kommenden neuen Features und Tools. Ich persönlich würde noch gerne ein Feature rund um die MethodHandles aus Java 8 sehen: Direkte Konvertierung von Method References (wie String::length) im Source Code durch den Java-Compiler zu MethodHandles (und die damit verbundene statische Prüfung) [6].

Geschrieben von
Uwe Schindler
Uwe Schindler
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.deTwitter: @ThetaPh1
Kommentare

Hinterlasse einen Kommentar

2 Kommentare auf "Java 9 Release verschoben: Warum Jigsaw noch nicht fertig ist"

avatar
400
  Subscribe  
Benachrichtige mich zu:
Jörg Prante (@xbib)
Gast

Gründe sind hier gut aufgeführt:
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-December/005454.html
Da ist keine Rede von Groovy.

Uwe Schindler
Gast
Hallo Jörg, danke für den Link! Der Listenbeitrag sagt aber auch was ich ja erwartet habe: „I personally am far from convinced that the compatibility of JDK 9 with 8 is going to be good enough. Especially as it seems to me that all libraries that use reflection are likely to be broken with 9, something that will significantly hamper adoption.“ – Damit lag ich ja nicht so falsch. Die Sache mit Groovy stammt aus einer anderen Diskussion – war aber auch nur ein Beispiel, schon aus dem Sommer. Das ist aber inzwischen größtenteils behoben. Das Groovy-Beispiel war aber exakt… Read more »