この1ヶ月の間、Java Modularity ワーキンググループ(JSR 294)の現状について多くの議論がなされた。JSR は、異なるモジュールシステム間(特に Sun の Project Jigsaw と OSGiについて)の共通基盤を見つけようとしているが、現在の提案はあまりにも複雑であり、世界初となるメタモジュールシステムという概念を導入している。
多くの議論は言語仕様と実装の違いに集中した。現状では、(ほとんどExpert Groupが嫌っている)JSR 294 ドラフトは、モジュール、バージョン、制約、依存性のコンセプトを'取替え可能な'外部のモジュール性プロバイダに委譲するメタモジュールシステムを定義している。残念ながらこれは、バージョン番号、依存性の共通基盤が存在しないことを意味しており、一つあるいは別のモジュールシステムのために開発したモジュールが、結局のところ他のモジュールと非互換になってしまうような事態につながる。
そのようなあいまいさは、OpenJDK Jigsaw 提案あるいは OSGi のどちらかで動作するモジュールシステムを早急に必要としている、Java コミュニティにとっては何の助けにもならない。多くの人が、OpenJDK はなぜ OSGi を再利用できないのかと尋ねた。–しかしその単純な答えは、OSGi はモジュール性のためだけには複雑すぎだということだ。コアスペック(モジュールレイアを定義している)は極めて小さいにもかかわらず。ライセンスに関する問題も、OSGi を採用できない一因である。
あいまいに定義されたセマンティクスと外部プロバイダが意味を決定づけるコンセプトのメタモジュールシステムを開発する代わりに、メーリングリストグループに投稿されたSimple Module System 提案は、メタモジュールシステムを捨て去り、両方のモジュールシステムがサポートできる共通点に集中することを掲げている。これは邪魔になっているいくつかの主要な違いである、(どんな場合でも、あらゆる場所で Java 開発者のための利益となる)モジュールバージョンの表記と、必要とするパッケージがエクスポートしているすべてのパッケージを暗黙的にインポートするという Maven モジュール依存性と同じような、モジュール依存性の定義に関する同意に達することになるだろう。
この事は、Java 開発者が Jigsawa と OSGi の両方で動作するモジュールを構築することを可能にする。たとえそれぞれモジュールシステムがより強力な拡張を持っていたとしても、大多数の Java ライブラリを構築しモジュールを提供するだけの開発者にとっては必要ないだろう。これによりモジュール提供者は使用する二つの非互換のフォーマットを選択することに煩わされずに、代わりに Java ライブラリのモジュール性に集中できる。動的モジュールシステム内でモジュールを使用する事により、より強力な動的モジュール性が利用できるようになるだろう。しかしほとんどの場合、静的なモジュール性で十分であろうが。
提案の重要な点は以下のとおり。
- 単純な可視性モデル – モジュールが別のSimpleモジュールを要求するとき、別のモジュールのすべてのコンテンツは依存するモジュールから可視になる。モジュールをまたがるパッケージの分割に対しての禁止事項はない。これは、現在 Jigsawa と同じで、OSGi のより表現豊かなモデルになじみのない、ほとんどの人々が期待していることだ。多くの人々が今日経験している Maven ベースのビルドシステムや現在のランタイム クラスパスモデルとも良く適合している。OSGi は、単純な可視性モデルのサポートを提供するために仕様を更新しなければならない。それは、Require-Bundle が bundle のすべてのパッケージをエクスポートするのとほとんど同等になる。
- 単一のバージョン番号スキーマ – 単一の共有されたバージョン番号スキーマは必須である。Simple Module System はバージョン番号スキーマを定義しなければならない、Jigsaw はバージョン番号スキーマを使わなければならない、OSGi はバージョン番号スキーマを変更して使わなければならない。バージョン番号スキーマは、compareTo() がバージョンを順序付けするために使用することができるように、自然順序付けを定義しなければならない。現在、OSGi は四つのパートのバージョン番号スキーマを定義しており、自然順序付けはそれに基づいている。Sun は OSGi のスキーマが Jigsawa の要求に合わないと表明していた。それらの要求は、バージョン番号スキーマと Simple Module System によって OSGi と Jigsawa で共有されるはずの自然順序付けを設計するために整理して集められなければならない。新しいバージョン番号スキーマをサポートするために、OSGi は仕様を変更しなければならない。
- モジュール メンバシップ – Simple Module System のために、モジュールのメンバシップはモジュール成果物のメンバシップ、例えば JAR ファイルやディレクトリと一致すると、コンパイラは仮定しなければならない。実行時、それぞれのモジュール成果物は自身の単一のユニークなモジュールと結びついたクラスローダを持つだろう。すべてのモジュール成果物からロードされた型は、この単一のクラスローダによってロードされ、この単一のモジュールのメンバーとなる。
- “ブラックホール”なし – この提案が真に価値あるものであるために、仕様において“ブラックホール”が無いということは最優先事項である。ブラックホールとは、ソースコード中でモジュールシステムの仕様を知らずに理解できない部分のことである。仕様は、バージョン番号、依存性の表現、モジュールメンバシップ、その他を含む Simple Module System の具体的なシンタックスと意味を明記しなければならない。Java 言語仕様は、自身の言語キーワードやオペレータを定義することを許可していない。module-info ソースファイルやモジュール メンバシップ ルールも同様でなければならない。
JSR プロセスの仕事のおかげで、一人もしくは何人かの人々は仕様を書く責任がある。Expert Group は議論するため、課題を指摘するため、あるいはドラフトを承認するためにある。ここしばらくの間、メタモジュールシステムに対するグループのメンバーからの共通の承認が無かった。そして Expert Group メンバー(Sun の社員を含む)の何人かは、現在のドラフトの課題を強調するために彼ら自身の提案を書く必要を感じていた。これは、Java の標準化されたモジュールシステムに挑み獲得するための最後の努力のように感じる。OpenJDK の Jigsaw の要求と OSGi の要求の両方が、外部実装への依存無しに完全に言語仕様内部で定義された Simple Module メカニズムによってかなえられることを望まれている。
おそらく最大の利益は、バージョン番号の表現について同意が得られたことであろう。OSGi は長い間 Sun を除くすべての Java ライブラリにとって十分な major.minor.micro.qualifier 書式を定義していた。Sun は 1.major.minor.micro.qualifier を使っている。しかし別の重大な違いは、OSGi において空の qualifier はバージョン番号の範囲の'一番下'の値であり、ほとんどの Java 開発者の共通する使い方や Jigsaw では、空の qualifier は'一番上'の値である。(すなわち、Jigsaw において 1.0.0 は 1.0.0.beta より大きいが OSGi では反対である。)このような特殊なケースを解決する共通基盤を見つけることは、モジュールシステムのバージョン要求に向かう良いステップとなるであろう。五番目の数字の追加の要求があるとしても、将来のバージョンの OSGi がサポートできるケースであろう。
メタモジュールシステムが Java のための Simple Module System に置き換えられることについてどう思うだろうか？