Java標準モジュールシステムの要件

作者 Alex Blewitt , 翻訳者 南 伸二 投稿日 2011年6月2日

セクション

エンタープライズ・アーキテクチャ,

設計/アーキテクチャ,

デベロップメント

トピック

JSR 277 ,

JSR 294 ,

JCP Standards ,

JCP ,

Java ,

言語 ,

プログラミング ,

OSGi

共有 |

原文(投稿日：2011/05/26)へのリンク

昨日、Mark Reinhold氏はJavaのモジュラリティの未来についての最初の公開ドラフトを投稿した。以前のJSR294でのやりとりとは異なり、Javaのモジュラリティに関する議論はSun/Oracleの閉ざされた扉の外側で行われ、OpenJDKにおける他の利害関係者、つまりIBMや他のJava SE、Java EEコミュニティのメンバなど、を巻き込んでいる、とこの話題に関するMark氏のブログ記事で説明されている。

これはドラフトなので、まだ議論される必要のある課題もわずかながら存在するが、Javaにおけるモジュラリティがどのようであるべきかについての共通認識を表している。そして、IBMの関わりによって、これまで以上にOSGiとの相互運用性がより強調されている。

要件に関して興味深いのは、その意図がServiceLoaderとResourceBundleという現状モジュラリティに関してうまく機能していないものの上に構築しようとすることにあることであり、標準化されたパターンを利用したいと考える人が詳細を気にすることなくモジュラリティのメリットを受けることができる、ということだ。現時点では、ServiceLoaderは複数のクラスローダーに関しての問題を抱えている。

モジュラリティをJVMで有効化する主な狙いの1つがJVMライブラリそのものの分割を可能にするということだ。JVMライブラリはこの数年で数十メガバイトという大きさまでふくれあがっている。（Scalaはモジュラリティの概念を扱っていないが、同様にほぼ10Mバイトに到達している。） しかし、JVMライブラリのすべてのクラスは同じClassLoaderに含まれていることを想定してつくられている。OSGiはバンドル単位でクラスローダーを持っているので、これ自体はその直接の対応策ではない。（OSGiはfragmentという概念を持ち、親のクラスローダーに入れることはできる。） 単一のクラスローダー（すなわち、動的でない）でのモジュールシステムサポートの実現と複数のクラスローダでのサポートの実現はともに文書が要求する内容の一部である。

いくつかの表現は曖昧である。たとえば、バージョンは完全に順序がついている必要があるが、Semantic Versioningのような一貫したバージョニングスキームは現れていない。そして、メタデータが厳密に定義されていること（バージョン番号はその一部である）を要求する一方、バージョンの中身については自由な解釈が可能な状態になっている。

別の未解決の問題は、モジュール情報がコンパイルされたJavaコードとして利用可能であるべきか、宣言型の外部ライブラリとして利用可能であるべきかということである。OSGiは依存性をエンコーディングするのに既存のMANIFEST.MFファイルを利用するが、これまでのJigsaw実装はJavaクラスファイルをコンパイルして、ライブラリを通じてイントロスペクションを可能にしていた。Javaを変形することのマイナス面の1つは（MirahやJRubyのような）非Java言語でモジュールシステムを利用することが難しくなるだろうということだ。

この要件には賛否両論があるようだ。JRubyの主要開発者Charles Nutter氏はまだ仕様全体を読む余裕はなかったと断りつつ、すでにReinhold氏のブログにコメントしている。

おそらくアノテーションを含むであろう.classファイルがあることを要求することにより、jigsawモジュラリティシステムは言語がそこに対応できるかどうかに次のような不要な制限を課すことになる：

• 常に出荷前にJVMバイトコードにコンパイルすること
• Java言語の構成物に対応するもの、たとえばアノテーションのようなもの、をソースレベルでサポートすること

言い換えると、JRuby、JavaScript（Rhino）、Smalltalk（様々なもの）、Python（Rhino）、いくつかの他の言語は即座に排除されることになるだろう。

単にモジュラリティという以上の話を少しだけすると、この提案はJavaランタイムを他のシステムに移植する方法やその成果のWebパブリケーションとしての一般的なパッケージングシステム（rpmやeasy_installのようなもの）についても語っている。

この提案は、確かにまだ未解決の問題についての作業は進行中であるが、いくつかの肯定的な反応を引きつけてもいる：

この文書には本当にたくさんのよい要件があり、これが実現されることで確実にJavaは得るものがあるだろう - このことがオープンで受け入れられるやり方で行われたなら、であるが。

もう1つのよいことは、モジュール化がJava SE 8の一部になったら、OSGiに向かうことは今以上に容易になるということだ。現時点で既存のシステムをOSGiに移行することの最も大きな障害は最初の段階ではモジュラーな形で作られていないシステムのモジュール化であることがしばしばである。これは本質的にOSGiの問題ではなく、概念としてのモジュラリティについての問題である。もしモジュラーでない既存のコードがあるなら、それをモジュール化することは難しいかもしれない。Java SE 8によってこの問題は開発サイクルのより初期の段階で現れることになり、システムを初期の段階からモジュラーな方法で設計することが容易になるはずである。もし基本的なJVMモジュールシステム以上のものが必要なら、既存のJavaSE 8モジュールを持ち込んでOSGiに切り替えることができ、Java SE 8モジュールはそのままの形で動くだろう - つまり移行は楽勝だ。そして、OSGiの恩恵を受けられるようにモジュールを強化することできる。（下記参照).

Javaにおけるモジュール化は、Javaライブラリ開発者がOSGiランタイムで利用されるようなモジュールメタデータをランタイムに注記することを促進する一方、OSGi-liteパターンを可能にするかもしれない。既知の意見の食い違いはあるが、どちらの場合でも互換性を保った理に適った形で前進するすれば将来的にすべてのJava（そしてJVMベースの）開発者に恩恵があるだろう。

あなたは提案されたモジュラリティ要件をどう考えるだろうか？