Java 8 Module-System – die Karten liegen auf dem Tisch?

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.

Short URL for this post: http://wp.me/p4nxik-Ad
This entry was posted in Java Basics, Java modularization and tagged , . Bookmark the permalink.

4 Responses to Java 8 Module-System – die Karten liegen auf dem Tisch?

  1. Charles Nutter hat auch ausführlich im Blog von Mark Reinhold kommentiert:

    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

    In other words, JRuby, JavaScript (Rhino), Smalltalk (various), Python (Rhino), and several other languages would immediately be excluded.

  2. Ein weiteres Posting von David Bosschaert zum Thema, jetzt aber aus der OSGi Brille:

    So what does this mean for OSGi? OSGi is a widely used, mature, modularity standard today, existing for 10+ years.
    Well, the good news is that the new requirements are not incompatible with OSGi.

  3. And, Peter Kriens kommented on the InfoQ posting a few hours ago:

    Mark Reinhold posted a list of requirement. The next phase for requirements is to see how to satisfy them. So what will happen when OSGi matches each of those requirements, what is the purpose of Jigsaw then?
    And I do believe OSGi matches virtually all requirements.

  4. Interessant finde ich allerdings, dass es zu Modularisierung und Java EE noch nichts gibt…

Leave a Reply