BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース Mark Reinhold氏はコミュニティから懸念出ているにもかかわらず、JPMS (Jigsaw)がパブリックレビューに提出されることを発表した

Mark Reinhold氏はコミュニティから懸念出ているにもかかわらず、JPMS (Jigsaw)がパブリックレビューに提出されることを発表した

原文(投稿日:2017/05/04)へのリンク

Mark Reinhold氏は、オラクルのJavaプラットフォームグループのチーフアーキテクトであるが、Javaモジュール、一般的にはJigsawとして知られているものがパブリックレビューに提出されると発表した。IBMとレッドハットが公式に懸念を表明したにもかかわらずである。OpenJDKメーリングリストのスレッドで彼は次のように書いている。

私たちはこのEGでパブリックレビューに進めるという合意に至りませんでした。メンバーの何人かが本来のJSRの提出物にも言及されておらず、また合意している必要条件にも記録されていないゴールに私たちが取り組まなければならないと主張し続けていることだけが理由です。しかし、広範なJavaエコシステムでもっとも関心を持たれていることにおいて、実際に約束しているゴールにあることを提供するためにこれは進めるべきです。それゆえ私は合意していないにもかかわらず、仕様をパブリックレビューに提出しました。

IBMのTim Ellison氏が返答で、なぜIBMが反対票を投じるつもりなのかに関して追加となるいくつかの背景情報を、彼や他の人の懸念の要点を述べながらかなり長いメッセージで公開した。

進捗を前に進ませたいことを私は理解していますが、EGの集合知を聞くことやそれらの意見を尊重することに価値があると考えています。executive committeeの代表者たちが仕様を進められる準備が整っているかに関してEGメンバーに話し、彼らの立ち位置を支持することが衝撃となるべきではありません。

すべてのコメントを読む価値はある。しかし問題の中で彼は一連の技術的懸念を挙げている。次のようなものだ。

不適当な分離 - モジュールにおいてエクスポートされていない(プライベートな)パッケージは厳密に実装の詳細であるべきです。JPMSがレイヤごとに単一のクラスローダをデフォルトにしているということは、パッケージプライベートが同時にロードされたとき驚くべき競合が起こり得るということを意味します。

自動的なモジュール化における命名 - モジュールの依存性はモジュール名で記述されます。実装者が提供する標準APIはすべて同一のモジュール名を使わなければなりません。しかし、自動的なモジュール化における命名は実装の詳細であるJARファイル名をベースとします。私たちはモジュール名が一連のAPIの簡易表現なのか、それとも特定の実装なのかを決める必要があります。

アクセス制限はリフレクションをしているライブラリを破壊する - モジュールはあらかじめリフレクションに対して開かれているかを知らなければなりません。そしてリフレクション実行者のモジュール名を知らなければなりません。これは依存性注入(DI)などを破壊するでしょう。

最後の点に関してAntoine Sabot-Durand氏に話した。彼は現在パブリックレビュー中のCDI 2.0のスペックリードだ。レッドハットの社員として、彼はもちろんレッドハットとIBMの立場を支持しているが、こう言っている。

JigsawはCDI仕様の効果を限られたものにするだけでなく、実装となった際に衝撃は巨大なもの(リフレクションの部分、プロキシ処理、クラスローディング)となります。私が理解していることから考えると、Java 9はクラスローディングと可視性の問題をいくつか解決するかもしれない新しいレイヤAPIを提供しますが、ドキュメントが欠けておりレイヤへの切り替えは明確な保証がなく膨大な量の作業を意味するかもしれません。

SpringフレームワークのプロジェクトリードであるJuergen Hoeller氏が私たちにこう語った。Spring Framework 5.0 RC1もしくは4.3.8は最新のJDK 9 ビルド167に逆らって実行しているのだ。

  • 公開モジュールはリフレクション実行者の名前を知る必要はないのです。特定のモジュールへの露出を任意で制限するかもしれないというだけです。アプリケーションモジュールはほかのモジュールに対して簡単にそれ自身を一般的に公開すると宣言、あるいは特定のパッケージを一般的に公開するとして宣言できます。私の観点ではこれは十分便利ですが、もちろんJigsawにおける設計フローではありません。
  • エクスポートされた型でのリフレクションは公開の宣言がなくてもうまく動作します。パブリックでないフィールドを評価するかパブリックでないメソッドを最終的に呼び出すのかが、最終的に失敗するだけです。これが意味することは、アノテーションのためにエクスポートされたどんなクラスでもイントロスペクションできるということです。パブリックコンストラクタ/メソッドにあるそのようなアノテーションを見つけるだけである限り、どんな場合でもそれらの上で依存性注入を実行できます - 公開の宣言がなくても。
  • クラスの*パブリックでない*メンバを扱うために、モジュールは実際はそれ自身、もしくは少なくとも公開として装うパッケージを必要とします。これはプライベートフィールドへのインジェクションやプライベートフィールドへのデータバインディングを装います。Spring@ConfigurationのクラスとインタフェースでないAOPプロキシに対してCGLIBを使うのと同様です。そのため私たちはSpringで使えるように公開宣言することを推奨(必須ではないですが)しています。全体として見れば、現在のSpringフレームワークのJARをJigsawのモジュールパスにある"自動的にモジュール化されたもの"として使うというのはすぐにでき、十分スムーズに使えます。Springのための独自のコマンドラインフラグも必要ありません。アプリケーションはそれら自身のモジュール記述子でモジュールへの依存をJigsawの自動的なモジュール化における命名規約に従いつつ"spring.context"などで宣言するかもしれません。そのようなJARベースのモジュール名が当分うまく行く限り(私はSpring&#のJARと共通のサードパーティーライブラリにはそうするのがかなり好きです)、SpringベースのアプリケーションはJigsawをセットアップするよい体験をもう選べるのです。

とは言うものの、Hoeller氏はまたSpringベースのほとんどのアプリケーションがたとえJDK 9にアップグレードしたとしてもクラスパスのままであることを期待していると述べた。主としてHibernateのようなサードパーティのライブラリと簡単に統合するためだ。

新しいJava標準は25人のJava Community Process Executive Committeeメンバーの2/3の賛成で採用される。InfoQはHazelcastのChristoph Engelbert氏と話をした。Expert Groupメンバーの1人で、Hazelcastもまた反対票を投じる可能性が高いと示唆している。彼は私たちに語った。

思うに状況はきわめて複雑です。両側面ともに異なる点について正しいかもしれないのです。Mark Reinhold氏が言及した問題の1つは、例の機能がもともと必要条件ではなかったということです。これはおそらくほぼ正しいのですが、それをまだ強制することは開発の数年間で世界は変わらなかったということを意味します。これもまた明らかに正確ではありません。

概して、HazelcastではJSR376エキスパートグループ(EG)の合意が取れておらず、きわめて解決が難しいものとしてそれを扱う方法をスペックリードが見落としていると見なしています。私たちは票をまだ決めていませんが、コミュニティとEGメンバーとの議論に基づけばおそらく"反対"票を投じるでしょう。

誤解しないでください、Jigsawは重要な機能と言っていますが、もう少しの時間とそれを実際に遮断する方法が必要なんです。"大きな停止スイッチ"はいいものですが、それを有効にすると標準出力に警告が出力されます。これらの警告はOracleのバグトラッカーには課題としてないでしょうが、私たちのサポートチーム(少なくとも私たちのユーザや顧客)にはあります。これがほぼ反対票を投じるつもりである2つ目の理由です。

これがリリース日に対して重要であると理解していますが、よりよい合意が重要であり、Executive Memberの一員であることがJavaのエコシステムを本来の形で維持することだと考えています。現在の状態ではJigsawはまだ、アプリケーションと同様に多くのライブラリやフレームワークへの問題となるかもしれません。

しかしながらInfoQは別のエキスパートグループメンバーからも学んでいる。Azul Systemsだ。彼らは賛成票を投じる可能性が高い。CTOのGil Tene氏は私たちに語った。

これに関しては私たちは少し意見が別れています。私はJava開発者にとって役に立つモジュールシステムとして、Jigsawについてのいくつか(すべてではなく)の異議には賛同します。個人的には、単一のアプリケーションに存在する同一モジュールの複数バージョンへのサポートがないのは、JDKを別とすれば実世界で実際のよくあるケースで関心があることに関して有用性が制限されそうです(私のアプリケーションはmavenセントラルのパッケージAとBを使っており、その両方がモジュールCに依存しますが、AはC.1.1.0を要求し、BはC.1.2.1を要求します)。

しかし、すべての異議を鑑みても私たちは"賛成"票を投じると思います。異議の多くは機能不全のコミュニケーションと過剰な期待から来たものです。もっともな異議にもかかわらず(Java SE 9に対して計画されている)Jigsawへの願望は本来のものより過剰に多くなっています。私はそれを主にJDK内部で利用するためのモジュールシステムとして却下してよいのか、説明できません(これは危機的なJava SE 9という観点からそれを見ていることに由来します)。個人的には、今あるJigsawはJDK外で利用するには制限があると見ています。とくに世にあるライブラリや再利用可能なコードになるとそうです。たとえば、JDK自身は決して複数バージョンを扱いません。なので現状のJigsawはそこではうまく動作します。期待としては、今後現れる"本当のJigsaw"(Jigsaw 2.0?)ではJDK開発者でない人たちにも広く有用であってほしいです。Java 10?それとも11?そんなものはないということにならないことを願います....しかしJDK内のJigsawは完了に近づいており始める準備ができています。私にはJigsawを完全に再実施することを願ってJava SE 9を思いとどまらせる、もしくは大きなチケット項目にいくつか取り組んで、それにより列車全体を遅らせてしまう理由を説明できません。

私たちが接した人々の大半はまだ決め兼ねていると言っていた。たとえばMartijn Verburg氏は、LJCの代表だが、私たちに語った。

スペックリードとエキスパートグループにとってレビューに提出されたJSRに全体として激しく反対するのはきわめてまれなことです。私は5年ほどECにいますが、こんな状況が以前に起こったことがあるか思い出せません。

投票締切は5月8日でJCP Executive Committeeは現在スペックリードとエキスパートグループのメンバーから出されたさまざまな状況を議論しています。幅広いJavaコミュニティのメンバーからの批判を考慮することも同様です。投票締め切り前の2日間の対面ミーティングがあり、議題の重要な項目となるでしょう。ロンドンJavaコミュニティはたしかにECを広く公平にJavaコミュニティを代表するものとして見ています。そしてJigsawが現在の形でJavaとそのエコシステムに役に立つのかそうでないのかを評価するためにうまく据えられていると感じています。

モジュール化は難しく、Jigsawチームはとてつもない量の、よく考え抜かれた設計と実装の作業をつぎ込んできました。とくにJava自体をモジュール化することを遅らせることについて、完了した作業を見るのを面倒に感じがちです。しかし、もしより大きなエコシステムが現在の設計/実装へのサポートを拒否すれば多様な選択を得られず、少なくともエコシステムに多くの不満を引き起こすでしょう。

興味深いことに、この話の私たちの最初の投稿のコメントスレッドにおいて、Red HatのDavid Lloyd氏はさらなる負担をして少し遅らせることで解決に至ることができるかもしれないという提案している。

思うに、最小限の受け入れられる状態に持っていくために変更を議論し、導入し、テストする必要があるので、数週間遅らせるのが誰にとってもおそらくもっともよい(そしてもっとも現実的な)選択でしょう。

5月8日に投票が締め切られたとき、次の週に何が起こるのかについて見ていく。

 
 

Rate this Article

Adoption Stage
Style
 
 

この記事に星をつける

おすすめ度
スタイル

BT