JCP ECはJavaプラットフォームモジュールシステムに反対票を投じた

今日、JCP Executive CommitteeのJSR-376(Javaプラットフォームモジュールシステム。Jigsawとしてよく知られる)への投票結果がJava Community Processのページで発表された。提案への賛成が10票、パブリックレビューへの反対が13票だった。

これに続き、公開討論と調査に集中する週となる。InfoQが以前と直近ではReinhold氏のJCP ECへの嘆願という記事で取材している。その中で、彼はこう言っている。

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

Executive Committeeはこれを気にかけ、提案は現在の形ではまだ準備ができていないとコメントで示し、応じたように見える。一部の関心は自動的なモジュール化における命名に関係していた。これはもしJARファイル中のmodule-info.classで名前を指定していなければファイル名から名前を作成するものであった。ファイル名は保証されていないので、ファイル名から明示的に宣言された名前に切り替えることは後方互換の方法では達成できなかった。問題はJavaコミュニティにかなりの害を引き起こした。Stephen Colebourne氏は、Joda TimeとJava 8 timeの作者であるが、今日に先立ちこう述べている。

自動的なモジュール化はモジュールが非モジュールに依存できるようにします。しかしこれはモジュール名ではなくファイル名に必要な項目を指定することによって達成されます。もしモジュールがファイル名に基いて公開されると、これは後に苦痛を引き起こします。新しいMANIFEST.MFの項目はどんなオープンソースプロジェクトでもモジュール名を選択し、即座にその選択を公開できるようにします。JPMSがMANIFEST.MFの項目を見るとき、値を自動的なモジュール化のための名前として使います。

コミュニティメンバーはいかなる犠牲を払ってもファイル名に基づいたモジュールのJARファイルを公開することを避けなければなりません。しかしコミュニティメンバーはこれからずっと新しいMANIFEST.MFの項目を含むJARファイルを公開できます(技術的にはMANIFEST.MFの項目はまだ完了していませんが、おそらくもうすぐでしょう)。

自動的なモジュール化における命名に関するフィードバックはエキスパートグループのメーリングリストですでに報告されていた。そしてパブリックレビューのドラフトは現状で承認されるだろうという希望とともに公開されていた。しかし、ここ数日にわたってReinhold氏は自動的なモジュール化における命名の問題を認めた。これはメーリングリストにおいて提案を修正したことに至った。しかし、これはJCP ECに承認されたパブリックレビューのドラフトに含まれなかった。最終提案には含まれないとメーリングリストで話し合われていたので、メンバーはコメントで今の内容では提案に賛成できないと述べていた。

LJC(訳者注: ロンドンJavaコミュニティ)は提出された仕様に対し、投票期間の開始時点で"反対"を投票しています。投票期間の14日間の間、スペックリードとEGによっていくつかの困難な問題、たとえば#AutomaticModuleNames(自動的なモジュール化における命名)などで合意に至るようにすばらしい進展がありました。

しかし、私たち[SAP SE]はエキスパートグループでの直接的なコミュニケーションが欠如していることにとくに問題意識があります。このJSRが必要な3分の2の得票で承認されなかったと仮定すると、エキスパートグループとスペックリードは30日を追加して正規の会議のために使うと思っています。残った問題を整理し新しく、より持続可能で将来を考慮した提案を考え出すためです。関心事のすべてに対処はできないとわかっていますが、残りの期間できちんとよい折衷案(たとえば"自動的なモジュール化問題")がまだ可能であることを証明できると考えています。そして追加期間は再審議の投票に向けてよい仕様を提出するために使えると確信しています。

フィードバックはおおむねポジティブで、現時点としてはJPMSの実装において重要な作業がなされたと認めていた。投票の3分の2を下回ったので、パブリックレビュー期間は現在30日間追加延長されている。提案を更新して提出するためだ。メーリングリストでの議論を反映したものに基いて次の投票は実行される。たとえば自動的なモジュール化における命名体系の修正などだ。しかし議論はブログ投稿でなくメーリングリストで行われるべきだと助言もしていた。

最後に、私たちは全メンバーとスペックリードがテーブルに戻り、ブログやオープンレターを通じて互いに責め合うのではなくお互いに直接コミュニケーションしてくれるよう嘆願します！

JPMSに反対する票はないと見る人もいるかもしれないが、現時点のJSRはまだ作業中であり、 最終投票に行く前に解決の必要がある粗い部分があるというのが現実である。パブリックレビューは30日間以内なら再実施できる。パブリックレビューはさらなる問題を特定すべきで、その後問題を明らかすることができる。しかし、一度JSRがパブリックレビューを通過すると、最終レビュー投票に入る。これは再実施できず、まさに最終である。OpenJDKの実装(コードはすでにある)に影響はしないが、他のJavaプロバイダがJavaに準拠するために実施する必要があることに影響するだろう。オラクルにとっての代替案は完了していない仕様を急ぎで終わらせるための手段としてJCPを変更するか解散することだ。Martijn Verburg氏はロンドンJavaコミュニティのブログに投稿し、LJCが反対票を投じた理由を説明した。

これはJCPが何のためのものかということです(単に政治のためだけではないのです)。

ただの参加者や技術メディアのいくつかは、要はこれが大企業の政治だという結論となる可能性が高いでしょう。最近の公開ブログ投稿とオープンレターはこの感情をあおるでしょうが、私たちはみなさんに"反対"に付随するコメントを読むよう勧めます。

オラクルはJavaの管理人ですが、JCP Executive Committee (EC)は全体としてJavaのエコシステムに対するガイドとして活動することを意図しています。このケースでは意図したとおりに動いていると強く感じています。

LJCからECへのもう1人の代表者Ben Evans氏がInfoQへ語った。

LJCはJigsawの発足以来ずっとサポーターでした。Javaアプリケーションをパッケージングしデプロイする方法を根本的に変更することに含まれる複雑さを強く認識しています。しかし、これはモジュールシステムを最初の時点で正しいものにすることができなくなる危険さえあります。

最後の数週間、とくにJPMS JSRがレビューに提出されて以来、エキスパートグループは未解決問題の解決に向けてすばらしい進展がありました。しかし、主な問題は残ったままで一般提供までに修正する必要があります。モジュールへのマイグレーション方針において自動的なモジュール化がもっとも関心を持たれている(たとえばとくにMavenベースのアプリケーション)と私たちコミュニティが指摘してきたように、自動的なモジュール化に対する修正提案がもっとも重要です。

さらに考える時間を取ることで、既存のコードにどのように適用するかについてEGがいくつかのガイダンスを提供すれば、ハックする日を何日か取って、コミュニティが新しい機能提案に対しどんな反応をするか見ることができるようになるでしょう。

JPMSはまだ大いなる可能性を持っています。しかし、一般利用の準備ができたと考える前にさらなる作業が必要です。

IBMのTim Ellison氏はブログ投稿を公開した。投票での彼らのコメントを補足し、未解決の問題を解決してほしいという要望を述べている。

エキスパートグループとスペックリードがいっしょになって密接に、そして建設的に仕様のドラフトを洗練する作業を継続するだろうと私たちは楽観的に考えています。 残ったいくつかの技術的問題が残っているこの状況を改善するため、JSR 376仕様は修正され、Java 9プロジェクトのスケジュールに重大な中断もなく最終ドラフト提案が提示されるだろうと私たちは自信を持っています。

InfoQはMark Reinhold氏にコメントをもらうため連絡し、返答をここで公開する予定だ。