 |
|
|
| 前のページ 1 2 3
|
|
| JSR 291をとりまく状況
|
本連載では「モジュラリティの向上」を現状で体験できるEquinoxを扱ってみました。いかがだったでしょうか。本連載で中心的に取り上げた「JSR 291: Dynamic Component Support for Java SE」ですが、2007年8月7日に仕様化を完了し、Final Releaseとして公開されました。英語ですがご興味をお持ちの方はぜひダウンロードしてみてください。
またOSGi仕様の定義団体「OSGi Alliance」より参照実装としてEquinoxが配布されています。
Sun MicrosystemsがJavaOne 2007でプレゼンテーションした「JSR 277: Java Module System」や「JSR 294: Java Language Modularity Support with Superpackage」は、第1回で解説した通り「JSR 291: Dynamic Component Support for Java SE（OSGi）」と機能的にとても重複しています。
Sun Microsystemsはこれまで3回行われてきた「JSR 291: Dynamic Component Support for Java SE」の承認投票をすべて反対しました。Sunは反対した理由として「JSR277」や「JSR294」と機能的に重複している点のほか、すでに仕様策定グループとしてOSGi Allianceがあり、JCPとして妥当ではないこともあげています。
これについて海外のJavaの識者の中では「政治的な対立ではないか」と揶揄されることもありました。しかし「JSR 291」のFinal Approbal Ballot（最終承認投票）も全体として賛成多数で可決されました。
とはいっても「JSR 291」はOSGi Allianceでリリースされている「OSGi Service Platform Core Specification Release4 Version 4.1」をそのまま公開しているものです。
「JSR 291」は既存のJava SEの環境を対象にした仕様です。モジュールの依存性を定義したり、モジュール間を連携させたり、JVMを稼動したままでのモジュールのインストール・更新を実現しています。ここまでの機能はJava SE 6でもOSGiフレームワークを利用することで実現することができました。OSGiフレームワークが導入されるだけでもかなりモジュラリティが向上した環境になるのではないでしょうか。
それでは「JSR 291」に対して「JSR 277」や「JSR 294」の利点はなんでしょうか。「JSR 277」はモジュール管理システムをJVMのレベルでサポートし、「JSR 294」は、モジュールの定義を言語仕様としてサポートするための仕様です。そのため「JSR 277」や「JSR 294」をJVMレベルでのモジュール管理システムとして位置づけています。現在「JSR 277」のExpert Groupにて「JSR 291」であるOSGiとどのように連携し、サポートするのかという議論が進められています。
「JSR 291」ではモジュールの依存関係の定義、またモジュールの動的なインストールや更新などを実現しています。しかし新しくインストールしたモジュールに不具合があったため、前のバージョンに戻すなど、モジュールの管理を支援する機能は、残念ながらありません。
「JSR 277」ではリポジトリという概念を用いてモジュールの管理を実現します。実行時に依存関係を検索して足りないライブラリをダウンロードすることなどを目的としています。RubyではRubyGems、PerlではCPANのように現在主流となっている軽量言語ではモジュール管理システムが整備されています。Javaでもこのリポジトリ機能が言語環境として取り入れられていれば、モジュールを扱えるプラットフォームとして非常に優れた環境になるでしょう。しかし、「JSR 277」ではモジュールの動的なインストールや更新などは考えられていませんでした。
また「JSR 291」ではMANIFESTファイルにBundleの定義情報を記述します。しかし、MANIFESTファイルですので、パッケージ名やバージョンが間違っているといった理由によるエラーをコンパイル時に判別することができません（Eclipseはプラグインを開発する環境であるPDEの機能により、MANIFESTファイルのエラーを発見することができます）。
これを言語仕様としてサポートするのが「JSR 294」です。言語仕様としてサポートすることで、Eclipseのような特別な環境を用意せずに、モジュール間の依存関係のエラーの発見を行うことができるようになるでしょう。
「JSR 277」や「JSR 294」の仕様策定メンバーで、かつ「JSR 291」で仕様策定リーダーのGlyn Normington氏はJSR 277とJSR 291の現状の解決策として次のものをあげています。
引用「The dream solution is clear: JSR 277 should adopt JSR 291, underpinned by language and VM support in JSR 294, and add the JSR 277 repository architecture.This would accelerate the progress of JSR 277 by several years and guarantee perfect interoperation between JSR 277 and JSR 291.」
訳「夢の解決策は明白です。JSR 277は、JSR 294によってVMや言語仕様に支えされたJSR 291をサポートし、JSR 277のリポジトリーアーキテクチャが導入されなければなりません。これは数年でJSR 277の進歩を速めて、JSR 277とJSR 291の間で完全な相互運用を保証します。」
上記はGlyn氏が描くJavaのモジュラリティの未来から引用したものです。
筆者もGlyn氏が描く未来に賛同します。この3つのJSRが対立させるのではなく、補完させてより良いモジュール管理システムが構築されることを望みます。Java SE 7のリリースまでには時間があります。今後仕様変更もたくさん行われることでしょう。本連載を通してJavaが今後どういった方向で進化をしていくのかを感じていただければ幸いです。
|
前のページ 1 2 3
|
|
|
|
|
著者プロフィール
株式会社チェンジビジョン 近藤 寛喜
モデリングツールJUDEを開発しているチェンジビジョンにて、プロジェクトの現在を見える化し、状況を共有することで現場で起きている問題を解決するためのツールTRICHORDを開発している。以前からオープンソースのプロジェクトに興味を持ち、特にEclipseプラットフォームに心酔している。最近はゲームの操作感を刷新したWiiリモコンを使って何か面白いUIが作れないか模索している。
|
|
|
|
|
|
