Java 8 ohne Modulsystem ist eine Schande – sowohl für Jigsaw als auch für OSGi-Entwickler

Hartmut Schlosser

OSGi-Entwickler – ruht Euch nicht auf Euren Lorbeeren aus! Wenn Ihr Eure eigenen Probleme nicht in den Griff bekommt, dann verdient es OSGi, nach Java 9 vergessen zu werden!

Diese deutliche Botschaft kommt von niemand anderem als OSGi-Entwickler Neil Bartlett selbst, der seine Community davor warnt, die Verschiebung des Modulsystems „Jigsaw“ von Java 8 auf Java 9 als Sieg zu betrachten.

In der Tat konnten sich OSGi-Entwickler nach Mark Reinholds Beurteilung, Jigsaw sei noch immer nicht bereit für ein Java-Release, einige hämische Bemerkungen nicht verkneifen. Um die Gemengelage besser zu verstehen, blicken wir kurz zurück:

Hitzige Debatten um die Art und Weise der Modularisierung der Java-Plattform hatte es seit der Lancierung des JSR 277 im Jahr 2005 gegeben. Entgegen standen sich die meist Sun-nahen Befürworter des JSR 277, welcher später in das von Oracle angeführte Projekt „Jigsaw“ überging, und das Lager der OSGi-Entwickler, die mit ihrem im Embedded-Bereich entstandenen Modulsystem eine bereits fertige und seit mehreren Jahren produktiv eingesetzte Technologie mit in die Diskussion einbrachten.

Höhepunkt dieser Debatte war wohl James Goslings Schmähung von 2009, „OSGi´s just too much fat„, mit dem darauf folgenden offenen Brief von OSGi-Begründer Peter Kriens, der dem Jigsaw-Ansatz Simplizismus vorwarf. Seither haben sich die Wogen zwar etwas geglättet, und man hatte sich zuletzt darauf geeinigt, dass ein Jigsaw-Modulsystem perfekt mit OSGi zusammenarbeiten müsse (siehe Projekt Penrose). Dennoch blieb im OSGi-Lager die Einstellung verbreitet, man hätte im Grunde den besseren Ansatz für die Modularisierung der Java-Plattform in der Tasche. Auch der Vorwurf, OSGi aus rein politischen Erwägungen nicht in Betracht zu ziehen, ist immer wieder zu hören gewesen.

Und so ist Neil Bartletts selbstkritische Mahnung tatsächlich ein Novum in der Debatte, da sie auf erfrischende Weise frei von Ideologie ist. Bartlett sieht den Grund für das Scheitern von Jigsaw in der unangebrachten Vergrößerung des ursprünglichen Fokus des Projektes.

Zu Anfang der Debatte ging es nämlich nur darum, das Java Runtime Environment (JRE) zu modularisieren – und dies kann nur innerhalb des JRE als Teil des Java Core realisiert werden. Hier habe Jigsaw durchaus eine Lösung parat, die nicht so weit von einem für das JRE-optimierten OSGi-Ansatz entfernt sei, sagt Bartlett. Das Problem beginne aber dann, wenn man versuche, Jigsaw auf den Bereich der Java-Anwendungen und -Bibliotheken auszudehnen.

After building themselves a shiny new hammer for the JRE, the Jigsaw developers started to see nothing but nails in the Java application and library space.

Hier bekommt man es nämlich mit einer Myriade von Spezialfällen zu tun, die nur durch eine generische Lösung abgefangen werden können – wie sie etwa OSGi bietet.

Und so spricht Bartlett aus, was vielleicht schon viel früher als Realität hätte akzeptiert werden sollen: Die Modularisierung des JRE und die Modularisierung von Java-Anwendungen und -Bibliotheken sind zwei völlig unterschiedliche Paar Stiefel.

Unverblümt gesteht Bartlett auch ein, dass OSGi nicht gut für die JRE-Modularisierung geeiget ist:

JRE has some very unusual problems that don’t affect normal libraries and applications, and OSGi’s general-purpose module support doesn’t look so useful for JRE modularity.

Und so sieht Bartletts Lösung vor, Jigsaw und OSGi nicht als Konkurrenz-Projekte anzusehen, sondern als sich ergänzende Lösungen. Anstatt zu versuchen, den Scope einer Lösung auf den Bereich der anderen auszudehnen, sollte man in Zukunft dafür sorgen, die jeweiligen Stärken der beiden Ansätze herauszuarbeiten und für bessere Integrationen zu sorgen.

Denn auch die Art und Weise, wie OSGi heute mit dem JRE interagiert, lässt noch viel zu wünschen übrig. Ein OSGi Bundle sollte idealerweise gänzlich von versionierten Packages abhängen, doch aufgrund einer JVM-Sicherheitsbeschränkung muss der gesamte java.* Namespace anders behandelt werden. Ein Workaround besteht darin, den Bundle-RequiredExecutionEnvironment Header zu nutzen, um die benötigte Java-Version für ein Bundle zuzuweisen. Außerdem liegen andere JRE-Packages wie javax.swing oder org.w3c.dom völlig unversioniert vor. Und es gibt überflüssige Packages wie javax.transaction, die dennoch von OSGi unterstützt werden müssen, was nicht trivial ist.

Ein modulares JRE hätte all diese OSGi-Probleme lösen können, schließt Bartlett. OSGi Bundles hätten ein JRE anfordern können, das ein spezifisches Set versionierter Module enthalten würde. Zur Compile-Zeit könnte dann gecheckt werden, dass innerhalb des Bundles nur die benötigten APIs genutzt werden. Auch der OSGi R5 Resolver könnte dann entsprechend angepasst werden, um beim Provisionieren von Bundles zu erkennen, welches Set von JRE-Modulen installiert werden muss.

Nun, vielleicht ist der Zug jetzt noch nicht abgefahren, eine solche Lösung neu zu diskutieren. Es wäre jedenfalls wünschenswert, wenn die Jigsaw- und OSGi-Entwickler alte ideologische Vorbehalte über Bord werfen würden und wieder zu produktiven Gesprächen an einen Tisch finden würden.

Die Zeichen dafür stehen gar nicht einmal so schlecht. Bartlett selbst signalisiert mit seiner Selbstkritik Verhandlungsbereitschaft. Und Oracle setzt in vielen Projekten selbst OSGi ein und lehnt die Technologie nicht wie seinerzeit Sun kategorisch ab.

Vielleicht wäre eine solche Lösung auch vor dem Schreckensdatum 2015 zu haben. Die jetzige Situation jedenfalls bezeichnet Bartlett als Schande – sowohl für Jigsaw als auch für OSGi-Entwickler.

So because of this scope creep it looks like we will not get the benefits of a modular JRE until at least 2015. This is a great shame for developers using OSGi just as it is for everyone else developing on the Java platform.

Geschrieben von
Hartmut Schlosser
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.