BT

Oracleがモジュールシステムを擁護

| 作者: Michael Redlich フォローする 15 人のフォロワー , 翻訳者 大田 緑 - (株)チェンジビジョン フォローする 1 人のフォロワー 投稿日 2017年8月30日. 推定読書時間: 10 分 |

原文(投稿日:2017/06/22)へのリンク

2017 Emerging Technologies for the Enterprise(ETE)カンファレンスの、タイムリなプレゼンテーションの1つは、Oracle JVM ランタイムのリード、Karen Kinnear氏のプレゼンテーション、Javaの未来:モジュールなどだ。このプレゼンテーションからいろいろなことが起きた。具体的に言うと、2017年5月8日、JSR376の公開レビューの無記名投票の前と後の出来事だ。

Kinnear氏は、開発者の生産性の拡張や、クラウド用に改善されたJava APIを含む、Java 9の目標を紹介した。Java 9特定のJEPレビュー後、Kinnear氏は、新しいJavaプラットホームモジュールシステム(JPMS)に注目した。これは、プロジェクトJigsawJSR 376として知られている。

Kinnear氏は、参加者たちに、モジュールについて、3つの質問を覚えておくことを勧めた。

  • 何か足りないものはあるか?
    • モジュールシステムは、モジュールグラフを構築している時に、足りないモジュールを検出する。
  • コンフリクトはあるか?
    • パッケージ間のコンフリクトも、モジュールグラフを構築している時に検出される。
  • 内部APIの変更は安全か?
    • モジュールシステムは、モジュール外部から内部APIにアクセスできないようにする。

Kinnear氏は、モジュールを既存のアプリケーションへ統合できると主張し、モジュールパスとクラスパスの違いを強調しながら、モジュールとパッケージ間の相互作用とアクセシビリティのデモを行った。それから、特に、互換性のない変更がある場合、下位互換性を維持しながら、開発者がどのようにJava 9に移行できるかについて話した。

OracleのJavaプラットフォームグループのチーフアーキテクトであるMark Reinhold氏は、2016年3月のホワイトペーパーにおいて、JPMSの目標について述べた。

  • 信頼できる構成
    • 不安定でエラーが発生しやすいクラスパスメカニズムを、プログラムコンポーネントが、お互いに明示的に依存を宣言できる方法へ置き換える。
  • 強力なカプセル化
    • どのパブリック型のコンポーネントが、別のコンポーネントにアクセスできるか、また、アクセスできないかを宣言できる。

ETEのKinnear氏のプレゼンテーション以来、いろいろなことが起きた。

Red HatのJBossアーキテクチャの部門長であるScott Stark氏は、JPMSに対する懸念、特に、Red Hatが、主要なJSRの提示案の目標に合わなくなると考えていることについて述べた。Stark氏は次のようにまとめた。

Jigsawの実装は、新しいモジュールシステムであり、Java自体をモジュール化するためにうまく動いています。しかし、JVM上に実際のアプリケーションのより広範囲な製品デプロイは、十分に試されていません。現在、広く実装されている、多くのアプリケーションデプロイのユースケースは、Jigsawで可能ではないか、重大なアーキテクチャのやり直しが必要でしょう。

IBMとRed Hatは、現在の形式では、JPMSに賛成しないと公言した。

合意が欠如しているにもかかわず、Reinhold氏は、公開レビューのために、JSR 376を提出した。これを進めれば、幅広いJavaエコシステムの最善の利益になり、私たちは実際に約束した目標を達成できると、Reinhold氏は述べた。また、公開レビューの無記名投票の日に、JSR376に賛成票を投票することを促すように、執行委員会(EC)に公開状を送った。Reinhold氏の努力に関わらず、JSR376は、公開レビューの投票を通らなかった

「反対」票の影響

Tony Printezis氏は、TwitterのJVM/GCエンジニアであり、5月8日の投票で反対票を投じたTwitterの理由を説明した。JPMSとJava 9の利点について議論した後、次のように語った。

JPMSに関する一番の懸念は、そのようなシステムで期待される利益をすぐに提供せず、Java開発者に混乱をもたらすことを証明しそうなことです。この重要な技術の広範囲に渡る採用が遅れることを心配しています。もしJPMSが本来の目標のいくつかをもっと総合的に達成するならば、現在、Java開発者が持っている、本当の痛みを扱えるでしょう。特に、エクスポートされていないパッケージ名の衝突は、このJSRの「非干渉」と「強力なカプセル化」の目的とは、間違いなく矛盾するでしょう。しかし、モジュールがもっと完全に分離されれば、エクスポートされていないパッケージとしてモジュールに隠すことによって、ビルドシステムは、同じパッケージの複数のコピーを十分サポートできるようになります。そのような疑う余地のない、即座に得られる利益があれば、開発者が、ソースコードをモジュール化するためにしなければならない大変な仕事を相殺できるでしょう。そして、より早急にJPMSを採用することを促すでしょう。

InfoWorldのインタービューで、Reinhold氏はJPMSを擁護した。

一番の誤解は、MavenビルドシステムがJava 9で動かないということだ。これは事実ではない。MavenはJava 9で問題なく動く。しかし、Surefireテストプラグインのマイナーな問題を含んで、Mavenプラグインは問題があったことをReinhold氏は認めた。

また、開発者の好きなライブラリ、フレームワーク、そして、ツールがJava 9では動かないと言う人たちもいた。Reinhold氏は、そのいくつかは、現在、本当かもしれないと認めたが、製品リリースでこれらが動く可能性は十分にあると言った。そのようなプロジェクトをメンテナンスする人たちは、Java 9への早期アクセスが可能となっていて、リリースに向けて準備できることにも言及した。だから、Spring BootHibernate Validatorのようなプロジェクトは、今ではJava 9で動くのだと言う。

Reinhold氏が引き合いに出した3つ目の誤解は、コードをすべてモジュール化し、フレームワークやライブラリもコンバートするまで、Java 9を使えないと人々が信じているように見えることだ。「それは事実ではない。」と彼は言った。開発者たちは、Javaランタイムがクラスやリソースファイルを探すために、従来通り、Java 9でJavaクラスパスを使用できる。ただ、Java 9のモジュールでは、開発者たちがクラスパスを使う必要はない。

ロンドンJavaコミュニティの共同創立者で、JClarityのCEOのMartijn Verburg氏が、JSR 376の投票に関して、InfoQに話した。モジュール化されたJVMの利点について尋ねた時に、Verburg氏は、次のように答えた。

Javaの使用の中心的な部分に関して、非常に沢山のセキュリティを提供します。内部的な、または、日常のJava開発者が使うには安全ではない、多くのJava APIを隠します。同等に安全なものを提供するために、機能的に必要な点がいくつか不足しています。Javaは、より小さなモジュールに分割されるので、ランタイムに、より小さなJavaを作成しなければなりません。Java 9に入るjlinkツールによって、実際に必要なものだけをインストールするように、アプリケーションをずっと小さなランタイムでデプロイできるようにします。典型的な例を挙げると、サーバサイドアプリケーションは、AWTやSwingのようなクライアントサイドのGUIが必要なくなります。これにより、Javaはより速く起動し、より小さなデバイスで実行できます。同様に、クラウドインフラストラクチャへ素早くデプロイできるようになります。

IBMのシニアテクニカルスタッフメンバのTim Ellison氏が、最近、JSR 376の合意を得る方法について述べた。Ellison氏は、次のように言った。

私たちは、JCP ECに再提示される仕様の改訂版を見るのを楽しみにしています。そして、最後には、ECがExpert Groupをサポートすることを期待しています。IBMが特に関心を持っているのは、Java 9に移行するエンタープライズアプリケーションのための、互換性とマイグレーションの話です。マイグレーションと、この分野で有益だと私たちが信じているJPMSのデフォルトのふるまいに関して、重要な変更がありました。

JSR 376は、今、最終草案の仕様に移ることが決まっています。最終仕様を公表する前に、小さな修正はあるかもしれませんが、今までの過程によって、JCPが、Javaの強力な新しい言語機能を作り出すのに使われることを示しています。仕様リーダーとしてのOracleと、このマイルストーンへ到達するために、自分たちの時間を捧げたExpert Groupの人たちを信用しましょう。

Reinhold氏は、最近、Java 9のGAリリースに対して、スケジュールの変更を提案した。Ellison氏は、次のように言った。

私たちは、JDK 9 プロジェクトで、初期リリース候補のビルドを6月22日に作成するという、現在のゴールに向かって作業を続けていますが、あらゆる可能な結果に対して準備を整えるため、JCPプロセスに進むために必要な時間を配慮して、GAの日付を調整することを提案します。具体的に言うと、GAの日付を、7月27日から9月21日へ、8週間遅らせることを提案します。

次のJSR 376 公開レビューの投票は、2017年6月26日月曜日に予定されています。引き続きご注目ください!

参考資料

記者について

Michael Redlich氏は、2008年から、参加者、スピーカーとして、2013年以降はETE運営委員会のメンバとして、ETEに積極的に参加している。

 
 

Rate this Article

Adoption Stage
Style
 
 

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT