[ThinkIT] 第1回：Javaはまだまだこれからだ！ (3/3)

TOP＞システム開発＞問題点4の解決案：JSR 291モジュールをダイナミックに追加／削除するなどのアプリケーションのライフサイクルの管理

先取りJava SE 7！

第１回：Javaはまだまだこれからだ！
著者：チェンジビジョン近藤寛喜 2007/8/2

前のページ 1 2 3

問題点4の解決案：JSR 291モジュールをダイナミックに追加／削除するなどのアプリケーションのライフサイクルの管理

   JSR 291はOSGi（Open Services Gateway initiative）と呼ばれる仕様をJava SEへ移植しようとしている試みです。OSGiとは、稼動しているJVMに対してモジュールをダイナミックに追加したり削除するようなアプリケーションのライフサイクルの管理を行うための仕様が策定されているものです。そのためOSGi仕様を実装しているフレームワークを使用するとアプリケーションを止めることなくモジュールの追加、削除を行うことができます。

   JSR 291で提案されている仕様の元となっているOSGi仕様では、モジュールをBundleという単位で扱います。このBundleをインストール／アンインストールすることで、モジュールの追加／削除をダイナミックに行います。

   BundleはJAR形式で圧縮するか、もしくは圧縮せずにフォルダ形式のまま配布を行いますが、JARファイルのメタデータであるMETA-INF/MANIFEST.MFにパッケージの公開情報、必要なパッケージ、クラスパスを記述することができます。実は前述したJSR 277とJSR 294で実現されているモジュールごとのバージョン管理や、複数のJARを1つのモジュールとしてまとめる機能、またモジュールごとの公開・非公開APIの制御などの機能はJSR 291の元となっているOSGi仕様ではすでに策定されています。

   例5に先ほどの例4のC.JAMのsuperpackage.javaと同等の宣言をしているMANIFEST.MFを示します。superpackage.javaではモジュールに含むパッケージをmenberとして宣言していましたが、Bundleを定義するMANIFEST.MFでは必要ありません。

例5：C.JAMと同等のBundleのMANIFEST.MFの例


		Manifest-Version: 1.0

		Bundle-ManifestVersion: 2

		Bundle-Name: Hello Plug-in

		Bundle-SymbolicName: org.foo.xml

		Bundle-Version: 1.2.3

		Import-Package: org.foo.soap="1.3"

		Export-Package; org.foo.xml

   このMAFNIFEST.MFで注目していただきたいのはImport-PackageとExport-Packageです。Import-Packageはモジュールに必要なパッケージを宣言し、Export-Packageはモジュールから外部へ公開するパッケージを宣言します。

   JSR 277とJSR 294の実装は、まだ公開されていません。正式なリリース前に、どのような動きをするのかを試せるEarly Accessは、2007年末ごろに公開されるようです。JSR 291の元となっているOSGiはそれだけでモジュラリティの向上をさせる目的もあったため、JSR 277の機能をほとんど内包した形で提案されています。

   この2つのJSRでは大きな差異は2点あります。1つは機能的な差異です。JSR 277はモジュールを管理するリポジトリという機能が提案され、JSR 291はモジュールをダイナミックに追加／削除ができる機能が提案されています。

   もう1つの差異は、JSR 277はJSR 294のsuperpackage機能とアノテーションを組み合わせてパッケージの公開・非公開の制御を行う点です。この拡張の対象はJava SE 7以降に絞られています。

   それに対してJSR 291ではMANIFEST.MFに記述する形式であることから、Java SE 7以外でも利用可能という利点があります（詳しくはJSR 291のスペックリードであるGlyn Normington氏のBlogをご参照ください）。

Mind the gap: Comparison of JSR 277 and JSR 291 features
http://underlap.blogspot.com/2007/06/comparison-of-jsr-277-and-jsr-291.html

   実はJSR 277とJSR 294の組み合わせはSun Microsystemsが推進しており、言語仕様としてJSR 294がJava SE 7に取り込まれる可能性が高くなっています。JSR 291（OSGi）は、現行のままの形でJava SE 7に取り込まれないかもしれません。

   しかしJSR 291のベースとなっているOSGiはすでに多くのプラットフォームで稼動しています。例えば、現在多くのプログラミング言語の統合開発環境となっているEclipseはOSGiベースのフレームワーク「Equinox」上で動作しています。

   そのためJavaにおけるモジュール作成、配布形式のデファクトスタンダードとしてBundle形式が使われつづける可能性はとても高いでしょう。このEquinoxはOSGi R4の参照実装として位置づけられており、JSR 291の参照実装にもなる可能性は高くなっています。

   そこで本連載では、OSGi仕様が実装されたEclipse Equinoxフレームワークを取り上げ、Java SE 7が目指している世界を先取りして体験してみましょう。次回は、実際にEquinoxフレームワークの環境を整えてきます。

前のページ 1 2 3

著者プロフィール
株式会社チェンジビジョン近藤寛喜
モデリングツールJUDEを開発しているチェンジビジョンにて、プロジェクトの現在を見える化し、状況を共有することで現場で起きている問題を解決するためのツールTRICHORDを開発している。以前からオープンソースのプロジェクトに興味を持ち、特にEclipseプラットフォームに心酔している。最近はゲームの操作感を刷新したWiiリモコンを使って何か面白いUIが作れないか模索している。

この記事の評価をお聞かせください
ボタンをクリックしますとウインドウが開きます。
ご意見、ご要望にお応えします！インプレスIT INSIDE

INDEX
第1回：Javaはまだまだこれからだ！
	Java SE 7におけるプラットフォームの強化とは
	Java SE 7における重要な拡張～それはモジュラリティの向上
	問題点4の解決案：JSR 291モジュールをダイナミックに追加／削除するなどのアプリケーションのライフサイクルの管理

先取りJava SE 7！
第1回	Javaはまだまだこれからだ！
第2回	OSGi仕様が実装されたEquinoxを試す！
第3回	体験！モジュールの動的な追加と削除
第4回	Bundleの連携の制御の仕組みを理解しよう！
第5回	Javaはどこへ向かうのか？