Reinhold氏はJCPにJPMS(Jigsaw)の承認を懇願するオープンレターを掲載した

Mark Reinhold氏は、オラクルのJavaプラットフォームグループのチーフアーキテクトだが、JCP Executive Committeeへのオープンレターを掲載した。オープンレターで彼はIBMがJSRに反対票を投じる決定したという思いがけない出来事を説明し、レッドハットの反対票の決定は"彼らが作った非標準のモジュールシステム、これはJBoss/Wildflyのエコシステム外では殆ど使われていないが、それを守りたい"という動機によるものと主張している。彼は懇願を続けた。

どのように票を投じるかみなさんが考える際、私はみなさんに仕様をそのメリットで判断するよう、またみなさんの票が設定することとなる、先例の性質を考慮するよう要請します。

EGでの合意が欠如していることにより、このJSRへの反対票はJavaコミュニティプロセス自身への反対票です。プロセスは合意を強制しません。理由があるのです。 スペックリードに意図的に広い決定権を与えています。正確にはEGメンバーが彼らの狭い関心を守るために進展を防ぐことがないようにするためです。この権限を奪い取れば、未来のJSRは利己的な"エキスパート"の合意となることが決定的となります。

失敗した多くのテクノロジはまさにこのように設計されてきたのです。

これは私がJavaに望む未来ではありません。

この騒ぎへの返答としてレッドハットのDavid Lloyd氏は、彼が考えていることが未解決の問題であるとことについて要約を公開した。手短には次のようなことだ。

• 実行時にモジュール間で存在するサイクルをを許可する。
• (まだとても小さい)モジュールプリミティブのパッチを(区分的にもし必要なら)再評価する。
• モジュールパスにあるモジュール間でのパッケージの名前空間における分離性を提供する。

Lloyd氏は追記している。

私たちはコミュニティが対処すべき抜本的な変更がまだ反映されるかもしれないということにも関心があります。これがほかのECやEGメンバーにとってまだ交渉を難航させるものとなる可能性があります。現状のまま前に進める前に、残りのEGとの合意を保証することはよいアイデアであると思います。

レッドハットがJBossモジュールを守ろうとしているというReinhold氏の主張に関して、Llyod氏はInfoQに語った。

私はそれに失望しました。しかしそのときMark氏に言ったように、私たちが直面している問題を記述するのに私たち自身の経験を利用することは役立つと思います。これらのケースの例を推定することは難しくないだろうという期待があります。エキスパートへのメーリングリストで公開しているやりとりだけでなく通常のコミュニティへの返答からも私が考えている問題が私たちのソフトウェアに限ったことではなく、他の多くのソフトウェアやコンテナの作者やユーザが遭遇する可能性があることを代表しているということを明らかにすべきです。

モジュールパス名の問題で、Reinhold氏はまた、よりMavenに配慮し#AutomaticModuleNames(自動的なモジュール化における命名)のために更新した提案を提出している。これはJARファイル内のpom.propertiesファイルに利用可能なMavenのグループ識別子があるとき、モジュール名が衝突する可能性を低くするためにグループ識別子を含むようにする。

#AutomaticModuleNamesは開発者が自身のコードを使っているライブラリやフレームワークがすべてJigsawをサポートするのを待つ必要なくモジュールに分割し始められるよう設計されている。

JARファイルのマニフェスト属性、JARファイルがモジュールパスに置かれた時にJARファイルによって定義される自動的なモジュール化での名前としてAutomatic-Module-Nameの値が使われる。これが提案の鍵となる部分である。もしモジュールパスにあるJARファイルがそのようなマニフェスト属性を持っていなかったら、その自動的なモジュール化での名前は現在のファイル名ベースのアルゴリズムを使って算出される。Reinhold氏は次のように提案する。

このメカニズムでライブラリのメンテナは少しの労力で安定したモジュール名を得ることができます。たとえばMavenではマニフェスト属性はプロジェクトの'pom.xml'ファイルに数行追加するだけでできます。ライブラリのメンテナは早期に安定した名前を得ることができます。ライブラリが依存するものがすべてモジュール化される前にそうできるのです。それに依存するライブラリやアプリケーションが個別にモジュール化できるようにしてくれます。

Javaモジュールの提案はオラクルの12年以上の膨大な作業を表す。これはJSR 277から始まった。もともとJava 7で計画され、8となり現在9となっている。開始以来議論が付きまとってきた。しかしこの点で、コミュニティ間でJigsawはJDK自身を分解するためにとても必要な解決策を提供するものであるという合意が広く表れてきた。現状のままJava 9に入れば壊れてしまう、既存の多くのJavaツールに関心が寄せられている。