Javaはどこへ向かうのか？

開発を楽にするモジュラリティの向上とは

皆さまこんにちは。チェンジビジョンの近藤です。「第4回：Bundleの連携の制御の仕組みを理解しよう！」では、モジュール間の連携についてソースコードを基に解説しました。モジュール間を連携させることによって、どうやって動的な機能の追加を実現しているかということを解説しました。

機能を追加するための基となるBundleでは、接続されるサービスのインターフェースを公開しています。そして別のBundleでは、そのイン ターフェースに基づいてサービスを実装し、BundleContextのインスタンスへ実装したサービスを登録しました。    こうすることで接続元のBundleではソースコードを編集することなく、機能の追加を実現しました。OSGiはこうしたサービスの追加や削除、入 れ替えを自由に行うことができます。

さて最終回である今回は連載を振り返り、モジュラリティの向上がどれだけ開発を楽にするのかを解説します。

なぜJava SE 7でモジュラリティを向上させたいのか？

Java SE 7では、モジュラリティの向上が重要な位置づけになっています。これまで解説してきたようにモジュラリティの向上がもたらす最大の利点の1つは、機能の追加・削除が簡単にできることです。筆者はJava SE 7ではEclipseのようなプラグインシステムを目指していると考えています。

読者の皆さんはEclipse IDEを使ったことがある方が多いと思います。Eclipse IDEはプラグインによって、開発環境を容易にカスタマイズすることができます。これは機能を追加したいと感じていた開発者にとって朗報でした。開発者は追加したい機能を自らプラグインとして開発またはダウンロードして、開発環境へインストールすればよいのです。

例えば、Eclipse 3.3でほぼ標準的に組み込まれているMylynというプラグインプロジェクトがあります。

MylynはBTS（Bug Tracking System）と連携し、BTS上にある障害やタスクをEclipse上で編集することができるプラグインです。Mylynが公式にサポートを表明しているのは「Bugzilla」、「Trac」、「JIRA」です。これ以外のBTSへ接続するためのコネクタのインターフェースを公開しています。例えば 「Mantis」というBTSのコネクタは、Mylynのプロジェクト外で開発されています。

コネクタ部分の開発者は、コネクタを作成するときに実装しなければならないインターフェースに注目することで新しいコネクタを作成することができます。

たくさんのプラグインを動作させると問題となったのは？

プラグインを追加するようなシステムを構成する場合、問題となるのが「第1回：Javaはまだまだこれからだ！」で取り上げた4つの問題です。特に複数のバージョンを同一のVMで扱えないのはアプリケーションで利用できるライブラリの幅を狭めてしまいます。

また、Eclipseプラットフォーム上で多くのプラグインを組み合わせる時に、よく問題となったのがプラグインの相性問題です。現在はEclipseがOSGiフレームワーク上で稼動しているので解決されていますが、以前は複数のプラグインから同じプラグインの違うバージョンを呼び出すことができませんでした。そのため多くのプラグインを1つの環境へ導入する場合に、それらの依存関係が競合して導入できないことがありました。これがプラグインの相性問題です。

第1回で簡単に触れましたが、プラグインの相性問題を解決するために、Bundleごとに利用するBundleのバージョンを指定できるようになっ ています。OSGiフレームワークではMANIFESTファイルにて利用するパッケージとそのバージョンを「Import-Package」として指定し ます。すると必要なパッケージを持つBundleからクラスをロードできるのです。