プロジェクトJigsawまたはJSR 376としても知られるJava Platform Module System (JPMS)の通過できなかったパブリックレビューの最初の投票から約2ヶ月後、Javaコミュニティプロセスのexecutive committee (EC)は圧倒的多数の賛成で再投票を通過させた。InfoQが以前レポートしたように、公に“反対”票を投じると述べていたECメンバーであるIBMやレッドハットに、もともとの投票が締め切りを超えてしまった要因と、TwitterとロンドンJavaコミュニティが最終的に反対した理由はいくつもあった。
再投票では、レッドハット以外のECメンバー全員が“賛成票”を投じた。レッドハットは投票を棄権した。投票時のコメントで、レッドハットはこう述べている。
今回レッドハットは投票を棄権します。私たちは前回の投票からEG内で合意に至るための建設的な進展があったと考えていますが、このリリースに対して30日の延長期間内に取り組んできた多くのコミュニティの採択に影響を与えるかもしれないいくつかの項目が、現在の提案にあると考えているからです。しかし、私たちはJava 9のリリースを遅らせたくありません。スペックリードとEGによって提案されている、今後のJavaバージョンに対する意欲的なスケジュールをうれしく思っています。モジュールシステムに対する現実世界からのフィードバックを得ることは、今後変更する必要があるかどうかを、またその場所を理解する鍵となるであろうからです。プロジェクトリードとEGが継続して多くのJavaコミュニティからの情報に開かれていることを望んでいます。この30日間そうであったように。そしてOpenJDKの向こう側にいるユーザとコミュニティからのデータによって推進されるJavaの進化を楽しみに待っています。
Twitterは、もともとの投票では“反対”を投じたが、再投票では票を変更した。Tony Printezis氏は、TwitterでのJVM/GCエンジニアであるが、彼のブログでこう述べている。
JSR 376 Expert Group (EG)は修正したJSR 376仕様でいくつかの曖昧さをはっきりさせるために精力的に仕事をしました(#RestrictedKeywordsや#CompilationWithConcealedPackages、#ResolutionAtCompileTime)。そして重要な変更をいくつかしました(#ModuleNameInManifestや強力なカプセル化の緩和)。
この作業の結果として、私たちはJSR 376のパブリックレビューの再投票で賛成票を投じる決定をしました。
デフォルトで強力なカプセル化を緩和することで重要な障壁を取り除くこととなり、少なくとも短期的にはJDK 9を採用しやすくなるでしょう。これらの変更で、JPMSはJDK 9でのリリースの準備ができているというよりよい合意がEG内でできました。
ロンドンJavaコミュニティももともとの投票で同様に“反対”を投じていたが、再投票では票を変更した。Martijn Verburg氏、ロンドンJavaコミュニティの共同設立者でありjClarityのCEOだが、氏とTim Ellison氏、こちらはIBMのシニアテクニカルスタッフのメンバーであるが、2人はこの投票についてInfoQにこう話した。
InfoQ「レッドハットが投票を棄権する選択をしたことに対してどう思われますか？」
Martijn Verburg氏 「これは個人的な意見/推測だということを申しておきます。思うにレッドハットが投票をこのようにしたのは、"賛成"票は(現在の形の)Jigsawが彼らの顧客とそのユースケースすべてに対応する準備ができていることを意味すると感じたからでしょう。現在の形のJigsawは土台として受け入れられるものではあるが、顧客とそのユースケースすべてに対して準備ができているわけではないことを明らかにしています。
Jigsawのためにレッドハットが解決しようとしていたいくつかの項目は、後日に延期されました。これらの項目が解決されるのがJava 9の更新リリースなのかJava 10なのかはまだわかりません。」
InfoQ「5月8日の投票移行で変更されたことは何ですか？」
Verburg氏「たくさんあります！具体的な技術詳細は議事録に取り上げられています。
主要なものは以下のことです。
- バージョン名のフォーマットについての合意
- 自動的なモジュール化のための名前関連のルールとこれらのもっともよい使い方に関する手引き(Mavenエコシステムにとって重要となる)についての合意
- 同一モジュールの複数バージョンを扱うことは今後解決することとする
- デフォルトとして強力なカプセル化を緩和することについての合意(即壊れてしまうアプリケーションは少なくなるが、代わりに警告となることを意味する )
- いくつかのキーワードの使い方を整理する(作業にEclipseコンパイラを使えるようにする)
InfoQ「投票を通過させるためにJSR-376に対して行われた変更や提供されたことは何か他にありますか？」
Verburg氏「 *非常に*重要なこととして、スペックリードとECは実際に電話会議をしてコミュニケーションとコラボレーションを改善する努力をしました。」
Ellison氏「5月8日に投票が締め切られてから技術的な変更が多数ありました[1]。いくつかはその時点で仕様が最終ドラフト提案の状態でさえできるような比較的小さいAPI拡張です。他のものは既存のコードをより簡単にマイグレーションできるように、またすでにあるライブラリやアプリケーションにJava 9のコンセプトをより広く適用できるようにサポートするための新しい機能です。エキスパートグループとして、(仮想的にではありますが)集まって未解決の課題を議論しました。初期リリースで"確定しなければならない"ものはどれか、Java SEの今後のリリースに延期するものはどの問題か、この段階で断念すべきものはどれかを決めました。
プラットフォームリリースの回数を増やすことでJava SEへの技術的拡張の活力とペースを確かにしていくことについて、JCP内でも議論がいくつかありました。このことは長年Javaをよくする役目を果たしてきた標準化されたプロセスと企業の利益が生産的に協力する場であるフォーラム内で達成されるべきことです。
これら2つのことを一緒にして、遅れているJPMSの項目のいくつかが程なくしてJSRのメンテナンスリリースのエキスパートグループで再び審議されることを私は願っています。さらに、初期リリースを明言することで、あらゆる機能拡張は何らかの現実世界の経験から得られるでしょう。
ブログ投稿にこのことについてもう少し書きました [2]。未解決の課題リストは文書化されています。[3].」
[1]https://www.jcp.org/en/jsr/results?id=5959
[2]https://developer.ibm.com/javasdk/2017/05/26/building-consensus-jsr-376-java-platform-module-system/
InfoQ「JSR-376で、さらに実施してほしい変更は何かありますか？」
Verburg氏「バージョニングとバージョンサポートに関して、もっと改善があればと思います。現在まだビルドツールがこれを解決しなければなりません。しかしこのことに関して、Jigsawからよい手引が出て来るといいですね。」
Ellison氏「モジュラリティは単発の設計ではありません。人々がそれを使い、予想していなかった問題が発生して、私たちが予測しなかったユースケースや業界の変化(クラウドやマイクロサービス、サーバレスなど)に適用するためにモジュラリティは進化していくだろうと思います。コミュニティとともに仕事をすること、Java SEが進化する際に現在のコードが動作しないということがないことや新しいフレームワークやプログラミングモデルへのよいサポートをすることを保証したいという私たちの顧客の関心が、いつも私の焦点です。」
Rate this Article
- Editor Review
- Chief Editor Action