Fast 18 Monate nach dem schleichenden Tod von JSR-294 scheint das Thema standardisierte Modularisierung in Java neu belebt zu werden. Mark Reinhold( Chief Architect of the Java Platform Group at Oracle) veröffentlichte gestern über sein Blog einen anscheinend seit Januar 2011 diskutierten Vorschlag für eine Requirementsspezifikation eines zukünftigen JSR “Java Platform Module System” . Dieser könnte im Rahmen des Umbrella-JSR 337 für Java SE 8 umgesetzt werden. Um dem Schicksal des eingangs genannten JSR und seiner “berühmt/ berüchtigten” Vorschläge zu entgehen, gab es nach Reinholds Angaben am Jahresanfang einen informellen “modularity summit” unter Federführung von IBM und Oracle. Teilnehmer waren Schlüsselfiguren aus “OSGi, Eclipse, Java SE, and Java EE communities”, die sich mit dem Ziel trafen die Requirements an einen Modulstandard in Java zu verstehen ohne auf ein bereits existierendes System zu verweisen.
Die Requirements enthalten unter anderem Forderungen nach einer Interoperabilität von OSGi-Bundles mit den neuen Java Modulen, die Einbindung von Mavenartefakten in das neue Modulsystem und die Möglichkeit der Installation von Modulen aus dem Web.
Der vermutlich größte Zündstoff wurde im Abschnitt 8 als offene Anforderungen zur Diskussion gestellt. Dazu zählen so prominente Themen wie
- neues Schlüsselwort in Java zur Kontrolle des module-level type und des Zugriffs
- Java-like syntax
- Java vs. Non-Java Source File names
Die Debatte um das Papier dürfte in den nächsten Tagen einsetzen, wobei nicht nur diese offenen Requirements zu Diskussionen führen dürften. Selbst die sog. “Fundamentals” des Kapitels 1 bieten mit Ihrer Forderung nach standardisierten Regeln für “Build-time, install-time, and run-time module resolution and linking” Szenarien, in die der praktische Java Entwickler, Buildmanager und Architekt noch viele Stunden intensiver geistiger Aktivität investieren kann. Hierzu kommentiert z.B. OSGi-Papst Peter Kriens:
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.
Einen kleinen Vorgeschmack auf die gesamte Tragweite des Themas geben der sehr gute Blog-Eintrag des JBoss Modules Project Leads David Loyd:
Therefore it is very important to allow (better yet, require) builds to use specific dependency versions when building, and allow version ranges only at install and run time, where version ranges are a much better fit.
oder die Twitter-Äußerungen eines gewissen Charles Nutter:
In other words, JRuby, JavaScript (Rhino), Smalltalk (various), Python (Rhino), and several other languages would immediately be excluded
Diese ersten Äußerungen in der Debatte lassen mich im Moment gespannt allerdings wenig hoffnungsvoll auf Java 8 blicken.
Charles Nutter hat auch ausführlich im Blog von Mark Reinhold kommentiert:
Ein weiteres Posting von David Bosschaert zum Thema, jetzt aber aus der OSGi Brille:
And, Peter Kriens kommented on the InfoQ posting a few hours ago:
Interessant finde ich allerdings, dass es zu Modularisierung und Java EE noch nichts gibt…