Sun Microsystems の主任エンジニアである Mark Reinhold 氏が、Sun JDK のモジュール化がいかにクールか主張している(リンク)。彼は、JDK の複雑さがプラットフォームをどれほど痛めているか、そして JDK 6u10 リリースの Java Kernel と Quickstarter 機能(参考記事)が JDK の長期にわたる相互にむすびついた拡大という問題への対症療法にすぎないということについて、すぐれた議論を展開している。
Mark 氏は現在の JDK がどうしてこのように巨大なものになってしまったのか説明するところから議論を始める。
JDK は、（今はまだ）宇宙ほど大きいわけではないが、やっぱり大きい。
どうしてこんなに大きくなったかというと、過去 13 年の間で、Java SE プラットフォームが、もともとは組み込み機器向けであった小さなシステムから、幅広い環境にわたる多彩なニーズに応える大規模なライブラリへと成長してきたからだ。
思いどおりに使うことのできる巨大で機能性の高いアーミーナイフをもつことができればとても便利だが、サイズが大きくなることにはコストがともなう。
彼はつづけて、JDK のサイズが大きいことによるデメリットを説明する。
JDK は大きく、相互に密接にむすびついている。全体的に見ると JDK はモノリシックなソフトウェアシステムとして構築されている。これに基づく開発では、Java 仮想マシンの柔軟なリンクメカニズムが実行時にすべてうまく動かしてくれることを信頼して、新しいコードを書くときや古いコードに改善をほどこす際にプラットフォームの別の部分を活用するのは、まったく自然なことだ。
しかし、こういうスタイルでの長年にわたる開発は、API 同士そしてその実装同士の予想外のむすびつきを生む結果となり、起動速度やメモリフットプリントの増大をもたらす。たとえば、単なる "Hello, world!" と表示するだけのコマンドラインプログラムが現在 300 を超えるクラスをロードして初期化し、そのことに、最近のデスクトップマシン上で 100ms を要している。クラスデータの共有などといった英雄的なエンジニアリングの努力が行われているにもかかわらずだ。もちろん、規模のより大きなアプリケーションでは状況は一層深刻である。
Mark 氏は、JDK 6u10 リリースの Java Kernel と Quickstarter 機能(参考記事)が十分であるとは考えていないようだ。
JDK 6u10 リリースの Java Kernel と Quickstarter 機能は、少なくとも Windows ユーザにとっては、ダウンロード時間と起動時間を改善してくれるが、これらの技術は問題を抜本的に解決するものではなく、長い期間にわたる相互にむすびついた拡大という症状への対症療法にすぎない。
JDK のモジュール化（ JDK をしっかり定義された別々の、しかし互いに依存する一連のモジュールに分割する）は、ダウンロード時間や起動時間、そしてメモリフットプリントといった重要な指標値を向上させるもっとも見込みのある方法で、問題を根っこから解決するものだ。
彼は、このモジュール化がプラットフォームに与えるメリットについて次のように続ける。
JDK をモジュールとして再構成するプロセスは、予定されていなかった相互のつながりをすべて明るみに出す。明らかになった相互のつながりは、そこで分析され、多くの場合隠蔽されるか削除される。これは引いてはロードされるクラスの総数を減らし、起動時間とメモリフットプリントを改善することになるだろう。
モジュール化された JDK があれば、ダウンロード時に JRE まるごとではなくて特定のアプリケーションを起動するために必要なモジュールだけを配布できる。Java Kernel はそういったソリューションに向かう最初のステップだ。しっかり定義されたモジュールが存在することのさらなる利点は、利用しようとしているアプリケーションの特定のニーズに合わせて、ダウンロードストリームを事前カスタマイズできることだ。
Weijun 氏は記事に対するコメントで、JDK がモノリシックなのは Java が依存性を管理する適切な方法をもっていないからだ(リンク)、と述べている。
JDK が大きいのは、Java がソフトウェアの依存性を管理する工業的方法を何一つ明確にしていないからだ。
そのため、確実に Java スタックをデプロイするには、ソフトウェアに巨大でモノリシックなモンスターをバンドルするしか方法がない。
ついでに言っておくと、このことは Sun と JDK についてだけ言えることで、サードパーティ製のものはこのかぎりではない。依存性管理が欠けていることによる最悪の結果は、JDK が肥大化したことではなく、管理しにくいアプリケーションが長い期間にわたって生産されつづけてきたことだ。そのなかではクラスパスがハードコーディングされていて、ライブラリのさまざまなバージョンが利用されている（なぜかというと、アプリケーションの開発やアップデートを独立的に管理できないのなら、自分のアプリケーションにバンドルせざるを得ない jar ファイルは、プライベートコピーを作成して利用したほうがよいかもしれないから）。
なぜ Java が J2EE サーバでだけ奮闘しているのかを理解するのに、そんなにむずかしく考える必要はない（J2EE は、基礎となる Java プラットフォームに欠けている管理機能を多少提供している）。
GeekyCoder 氏は JDK のモジュール化はおそらくほとんどの開発者にとって最優先事項ではない(リンク)、と主張している。
モジュール化は確かにクールかもしれないが、ほとんどの Java 開発者にとってはそれが最優先事項なのかは疑わしい。
あなたがブログへのほんの一握りのポジティブな反応を見て、それらが Java 開発者コミュニティ全体を代表する意見なのかどうかをすこしも考えずに心を揺さぶられるのではないか、不安に思っている。
もっとも多くの票を得たバグを修正することのほうが、ただ単に「クールな」ことに取り組むよりもよい戦略だと思う。
「顧客の声に耳を傾ける」というのはすでに捨てられた古い考え方ということか。でも明るい面に目を向けることにしよう。このコメント欄を見るだけでも、あなたには喜んで手伝ってくれる開発者が二人いるし、彼らとともに作業がうまく進むことを願っている。
Similarly Michael B 氏は、エンタープライズユーザは JDK のモジュール化のことを特に気に留めていない(リンク)と考えているようだ。
JDK （どちらかというと JRE か）のモジュール化はエンタープライズユーザとは完全に無関係だ。エンタープライズユーザは今の状態を好んでいるのではないかと思う。なぜかというと、モジュール化とは依存関係が生まれるということだし、そこからは DLL 地獄のニオイがプンプンするから。大事なのは、ひとまとまりだと配布もパッチも容易だという点。あと Java にはすぐれた上位互換性がある。「一度書けばどこでも動く」だけでなく、「一度書けばいつまでも動く」わけで、それはすばらしい投資収益率（ROI）をもたらしてくれる。これが、人々が .NET よりも Java を好む理由のひとつだ。MS の戦略はいつも、「最新機能が搭載された新しいバージョンが出ましたよ、再トレーニングしてアプリを入れ替えてくださいね」というものだ。MS の技術は寿命が短すぎる。Java プラットフォームはすでにモジュール化されている。モジュールは自分のアプリが必要とするサードパーティ製のライブラリだ。それらが十分に成熟したときに Sun がそれをプラットフォームの一部にする、というやり方を私は気に入っている。Java の成功のカギとなるのは堅牢さと信頼性だ。だからここらで戻って、残ったままになっているバグを修正してほしい。6u10 リリースはバグフィックスの側面がとてもよかった。
もっと情報を知りたい方は、ここ InfoQ の Java Platform トピック(参考記事リンク)や、テーマがもうすこし絞られている Java SE トピック(参考記事リンク)を見てほしい。