JDK8, OSGi & Jigsaw: Diskussion um Anforderungen an ein Modulsystem

Hartmut Schlosser

Mark Reinhold hat die Anforderungen an ein Modulsystem für Java 8 online zugänglich gemacht. Das Dokument entstand nach einem informellen „Modularity Summit“ in Ottawa, an dem im Januar 2011 Mitglieder von Oracle und IBM sowie Vertreter von OSGi, Eclipse, Java SE und Java EE teilgenommen hatten.

Peter Kriens von der OSGi-Alliance kommentiert das Papier in seinem Blog und stellt zunächst fest, dass alle genannten Anforderungen durch den OSGi-Standard erfüllt würden. Dennoch bezeichnet er die vorgestellte Lösung als „Vereinfachung“. Das vorgeschlagene „Jigsaw“-Modell basiere auf Maven und stelle im Grunde ein „Deployment-Modulsystem“, kein Sprachmodulsystem dar.

Das Hauptproblem bestehe darin, dass bei Abhängigkeiten auf Teile eines JARs alle transitiven Abhängigkeiten mitvererbt würden. Beim Deployment großer Projekte kommen so zahlreiche nicht benötigte JARs ins Spiel, was sowohl Speicher- als auch Inkompatibilitätsprobleme nach sich ziehen kann – ein Umstand, der von Maven-Usern oft mit dem sprichwörtlichen „Maven lädt das ganze Internet herunter“ quittiert wird.

Kriens plädiert dafür, bei den Abhängigkeiten zwischen Build Time und Runtime zu unterscheiden:

Despite common believe, we do not need fidelity across all phases between the build time and run-time; we need to compile against API and run against implementations that are compatible with that API. A good Java module system must allow me to depend on an API module at compile time and select an appropriate implementation at deployment-time. Forcing the compile time dependency to be the same as the run-time dependency creates brittle systems, believe me. The problem can be solved by separating the concept of a deployment module (the JAR) and the language module. Peter Kriens

Alex Blewitt beschreibt als weiteren Streitpunkt die Frage, ob die Modulinformationen als kompilierter Java-Code oder in Form einer externen deklarativen Bibliothek verfügbar sein sollen. Während OSGi mit der MANIFEST-Datei den deklarativen Ansatz verfolgt, hatte man bei Jigsaw bisher die Java-Klassen-Dateien kompiliert. JRuby-Leiter Charles Nutter kommentiert diesen letzten Ansatz, es würden so alternative JVM-Sprachen wie JRuby, JavaScript (Rhino), Smalltalk und Python (Rhino) ausgeschlossen.

By requiring that there be a .class file, probably with annotations in it, the jigsaw modularity system unnecessarily restricts participation to languages that:

  • Compile to JVM bytecode always before shipping
  • Support the full complement of Java language constructs, like annotations at the source level

Charles Nutter

Das Anforderungspapier hat aber auch positive Resonanz hervorgerufen. So beschreibt David Bosschaert ein Szenario, in dem die Modulsysteme von JavaSE 8 und OSGi wie zwei aufeinander abgestimmte Schichten miteinander harmonieren:

I congratulate Mark Reinhold and all others involved in this for providing the basic requirements and design proposal that will make OSGi work nicely with the JavaSE 8 module system. OSGi will extend the basic JavaSE 8 modules and both systems will work with each other to form a layered design. David Bosschaert

Die Debatte um die Modularität in JDK8 ist also neu entfacht, ist aber sicherlich noch weit von einer konsensfähigen Auflösung entfernt. Dass das Anforderungsdokument öffentlich gemacht wurde und zu den Diskussionen Vertreter verschiedener Parteien eingeladen wurden, zeugt jedenfalls von einer größeren Offenheit als dies noch zu Suns Zeiten üblich war, als die Jigsaw-Fraktion sich deutlich von den OSGi-Vertretern abzugrenzen versuchte. Sicherlich hat die Mitwirkung von IBM und Eclipse dazu geführt, dass Kompatibilitäten zum OSGi-Modell mit auf die Agenda genommen wurden. Vielleicht lässt sich die Modularitätsfrage nun doch im Einvernehmen mit den verschiedenen Playern lösen. Ein erster Schritt ist getan.

Geschrieben von
Hartmut Schlosser
Kommentare

Schreibe einen Kommentar

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