Modularisierung von Java: zweiter und letzter Versuch?

Inhaltsverzeichnis

Mitte letzter Woche ist es mal wieder passiert. Eine unscheinbare E-Mail von Mark Reinhold kam über die jigsaw-dev-Mailingliste des OpenJDK. Es gäbe jetzt einen neuen Prototypen von Jigsaw. Ein einfacherer Versuch soll es werden. Knapp 18 Zeilen pure Enttäuschung mit einem knappen "Mark" unterschrieben.

Jigsaw bezeichnet seit geraumer Zeit den Versuch, ein Modulsystem für Java einzuführen. Was mit dem JSR 277 (Java Modularity) bereits 2005 für Java 7 angedacht wurde und lange Zeit für Java 8 geplant war, wurde erst im letzen Jahr erneut auf unbestimmte Zeit verschoben. Aber warum benötigt man überhaupt ein Modulsystem?

Jigsaw hat den Anspruch, nicht nur ein Modulsystem für Java-Anwendungen zu sein, sondern auch eine modulare Java-Plattform tragen zu können. Dieses modulare Java könnte damit nahezu beliebige Konfigurationen bereitstellen, die sowohl komplette Server als auch schlanke Hardware unterstützen. Neben der puren Größe von Java-Installern (zwischen 35 und 51 MByte für Java 7u25) würde ein solches Konstrukt auch das modulare Laden notwendiger Bibliotheken ermöglichen und schließlich vermutlich auch die Laufzeit-Geschwindigkeit deutlich erhöhen.

Gerade hinter den letztgenannten beiden Punkten vermuten viele Oracles einzige Motivation, die JVM für mobile Endgeräte attraktiv zu machen. Hier hat es in den vergangenen Jahren immer wieder Prototypen gegeben, die eindrücklich gezeigt haben, wie ein Java auf iOS oder Android aussehen könnte. Auch wenn hinter den Prototypen bisher vermutlich komplette Portierungen eines gerade ausreichenden Ausschnitts der JVM gestanden haben, zeigt sich hier schnell der Vorteil einer modularisierten Java-Plattform.

Probleme bei Jigsaw

Eigentlich verwundern die andauernden Verschiebungen und Richtungswechsel die langjährigen Begleiter der Java-Entwicklung nicht.

"Started on a shoestring at Sun, barely survived integration into Oracle, only fully staffed about a year ago …" (@mreinhold, source: twitter)

Noch im Juli 2012, während der letzten großen Verschiebung, konnte man auf dem Twitter-Stream von Mark die wahren Hintergründe lesen. Das Projekt hat zwar einen großen Bekanntheitsgrad, aber kaum Unterstützung innerhalb von Oracle bzw. früher schon bei Sun. Die als durchaus begrenzt anzusehenden Entwicklerkapazitäten konnten auch aufgrund der vielen Sicherheitsprobleme von Java nicht in dem Maße für Jigsaw eingesetzt werden, wie das erwartet wurde. Abseits dieser Problematik haben die bisherigen Prototypen gezeigt, dass eine vollständige Modularisierung einige schwerwiegende Inkompatibilitäten zu bisherigen Sprachversionen nach sich ziehen würden. Diesen Schritt scheut man offensichtlich zu gehen. Da gerade die fast vollständige Abwärtskompatibilität eine Erfolgsgeschichte von Java ist, ist dieser Vorbehalt nachvollziehbar. Auch vor dem Hintergrund, dass die Modularisierung zur Compile-Zeit schon lange von Werkzeugen wie Maven, Ivy, Gradle und Co. bereitgestellt wird.

Wer braucht ein modulares Java wirklich?

An dieser Stelle fügen sich die ersatzweise in Java 8 eingebrachten Compact Profiles (JEP 161) gut in die bisherige Geschichte ein. Um dem Wunsch nach schlankeren JREs für spezialisierte Anwendungsbereiche nachzukommen, sind drei kompakte Profile identifiziert worden, die nur ein Subset der Funktionen aus der kompletten Plattform enthalten werden. Leider werden damit auch wirklich nur die bisher auf Java ME basierten Entwicklungen bedient. Das heißt, die Laufzeitumgebung selber wird in viel schlankeren Versionen (vermutlich bis unter 10 MByte) zur Verfügung stehen. Ob die erst kürzlich eingeführte Server-JRE auch auf dem gleichen Weg wie die Profiles erzeugt wird, ist unbekannt. Aber auch hier zeigt sich, dass Art und Anzahl spezialisierter JREs weiter steigen werden.

Weiterhin ungelöst bleibt damit der Anspruch, ein Modulsystem für Java-Anwendungen zu haben. Etwas Analoges zu OSGi, JBoss Modules oder anderen auf OSGi-basierten Vereinfachungen. Nicht nur Java-SE-Anwendungen würden von solch einem Ansatz profitieren, sondern auch auf Java SE aufbauende Plattformen wie Java EE. Gerade hier gibt es deutlich die Notwendigkeit zur Standardisierung eines Modulsystems. Auch wenn die meisten Server heute intern bereits auf OSGi setzen, bleibt es den Herstellern überlassen, ob und wie sie ein solches Modulsystem mit allen Vorteilen auch in die Hände von Anwendungsentwicklern geben. Und natürlich gibt es gerade im Umfeld fehlender Standardisierung auch eine Vielfalt von Lösungsansätzen, die nicht einfach portierbar sind. Die Verfechter von OSGi weisen hier inhaltlich ganz recht auf den Umstand hin, dass ihr Ansatz bereits seit langen Jahren etabliert und bewährt ist, und die dortigen Standardisierungsbemühungen umfassen zunehmend auch die Enterprise-Spezifikationen.

Java bekommt niemals ein Modulsystem

Alle geschilderten Probleme und Seiteneffekte werden ganz klar zu einem Ergebnis führen: Ein echtes Modulsystem wird Java niemals bekommen. Auf Seiten von Oracle wurde mit den Profiles das eigentliche Ziel bereits erreicht. Die Notwendigkeit, sich mit Modularisierung weiter auseinanderzusetzen, ist damit vermutlich hinfällig. Auf Seiten der Anwendungsentwicklung wird sich die Lücke zwischen Compile-Time-Modularisierung und OSGi hoffentlich mittelfristig schließen. Dabei spielt die OSGi Alliance eine wichtige Rolle. Sie muss den Ruf der OSGi-Gegner ernst nehmen und die vielfach bemängelte Komplexität durch konsequente Vereinfachung zumindest geschickt verbergen. Für die weiteren Java-Plattformen ist OSGi leider keine Antwort. Nachdem die OSGi-Spezifikation nicht im Rahmen des JCP stattfindet, ist die Wahrscheinlichkeit, dass eine Plattform diese Abhängigkeit definiert, gleich null. Es wird also weiterhin ein buntes Durcheinander bei den Servern geben und somit Modularität kein Themenfeld für neue Funktionsumfänge sein. Dies ist vordringlich für Java EE bedauerlich.

Siehe dazu auch:

• Java-Modularisierung: Zurück auf Los!; News auf heise Developer

()