osgiモジュールとjava 9モジュールの連携 - oracle...装、internet of...

ORACLE.COM/JAVAMAGAZINE ////////////////////////////// MARCH/APRIL 2018

32

//microservices and containers /

多くの開発者が経験してきたように、コードのモジュール化とは、単に Java パッケージを定義すればよいと

いうものではありません。モジュール化とは、どのコードをインポートするか、どのコードを公開して共有

するか、そしてどのコードを隠蔽するかを厳密に指定することです。適切に設計されたモジュールでは、わかりや

すい規約も定義されます。この規約は、共有コードがどのように動作し、相互連携を行うかに関する洞察を与え

てくれます（図1）。

Java SE 9では、Javaアプリケーションと Javaプラットフォーム自体をモジュール化できるようになりました。

一方で、Open Service Gateway Initiative

（OSGi）の提唱者たちは、2000 年代初頭

からJavaアプリケーションのモジュール化

を行ってきました。しかし、Java 9とOSGi

のアプローチには、いくつかの大きな違い

があります。本記事では、OSGi のモジュー

ルと Java 9 のモジュールを比較し、それぞ

れの長所を挙げるとともに、両方を組み合

わせて使う方法を例示しながら説明します。

Java 9 は、OSGiが提供するモジュー

ル機能の大半を実装していますが、OSGi

が特にうまく当てはまる事例もあります。た

とえば、ある種のプライベート・クラウド実

装、Internet of Things（IoT）ソリューション

（特に、デバイス側の IoTゲートウェイ）、プ

OSGiモジュールとJava 9モジュールの連携互いに補完し合う2つのモジュール・システムを併用する

ERIC J. BRUNO

図1：モジュール化によって、コンポーネントの公開方法や使用方法と、適切な使い方の規約が厳密に定義されます

Module AContrac ts

Module B

Module C

Class BClass A

My Application

Package APackage B

Dependencies

http://oracle.com/javamagazine

https://twitter.com/oraclejavamag

https://www.facebook.com/JavaMagazineOracle

mailto:JAVAMAG_US%40ORACLE.COM?subject=


33


ラグイン・モデルに適したアプリケーション（Eclipse IDEなど）、継続的に拡張性が求められる設計などです。し

かし、Java 9 のモジュール・システムには、Javaコンパイラのサポートという、OSGiにはないメリットがあります。

ここでは、モジュール化に対する2つのアプローチについて議論するよりも、コンポーネント、アプリケーショ

ン、JVMの観点から、それぞれが実現する独立性に焦点を置く方がよいと考えています。そこで、本記事では、

OSGiと Java 9 のモジュールを併用し、両方の優れた機能を使って理想的なソリューションを実現する方法につい

て考えます。

OSGiとは OSGi の始まりとなったのは、1990 年代後半に作成された JSR 8です。それ以来、その政治的、技術的な難しさ

を十分に経験してきました。OSGi は、単なるモジュール・システムではなく、Java向けの完全なプラットフォーム

であり、動的コンポーネント・モデルでもあります。OSGiを使用した場合、OSやJVMを再起動することなく、リ

モートからJavaコンポーネントやJavaアプリケーション全体のインストール、アクティブ化、非アクティブ化、アッ

プグレードを行うことができます。さらに、リモートからのJavaコンポーネントのダウンロードやインストールに

加え、管理ポリシーもサポートされている

ため、それらを組み合わせて完全なアプ

リケーション・ライフサイクル・モデルを

形成することもできます。

コンポーネントの動的な管理は、エ

ンタープライズ・アプリケーションでは必

要ないかもしれませんが、IoTや組込みシ

ステムの世界では有用です。一方で、OSGi

が提供する動的な部分は無視し、OSGi

モジュールのメリットだけを活用すること

もできます。OSGi のモジュールは、バン

ドルとして定義されています。各バンドル

には、カスタムのクラスローダが付属して

います。その結果、バンドルの外部から、

プライベートな内部クラスを直接参照でき

なくなるため、独立性が向上しています。図2：OSGiは、レイヤー構造を持つプラットフォームで、モジュールの定義や動的なコンポーネント管理が提供されます

Ser vices

Bund

les

Lifecycle

Modules

Secu

rity:

OS, J

ava,

OSGi,

App

OSGi E xecution Environment

Java Vir tual Machine

Operating System

Focus of modularity


34


さらに、バンドル内のオブジェクトはサービス間で共有され（図 2）、内部実装をさらに隠蔽しながら、コンポーネントの使用方法や通信に関する厳密な規約を定義します。このような高い独立性の結果、複雑さが緩和され、

実行されるシステムの透過性が増して、コンポーネントの再利用が促進されます。

図 2では、モジュールの定義に関連する主要な部分が赤枠で囲まれています。この図は、一般的なOSGiレイヤーの図とはあえて違う形にしており、セキュリティをOS、JVM、OSGi 環境、そしてアプリケーションのコー

ドに関わる共通の責任として示しています。セキュリティは、単一のコンポーネントだけが責任を負うものではあ

りません。リスト1に、シミュレータ・アプリケーションに使う数値演算ライブラリの一部をOSGi バンドル化したサンプルを示します（リストには、4つのファイルが含まれています）。

リスト1：OSGi バンドル実装サンプルの抜粋package example.simulation.math;public interface SimulationMath { double degreesToRadians(double degrees); double getTargetAngle(double centerOffset, double targetDistanceZone); //...}

package example.simulation.math.impl;import example.simulation.math.SimulationMath;public class MyMathImpl implements SimulationMath { public double degreesToRadians(double degrees) { //... return radians; }

public double getTargetAngle(double centerOffset, double targetDistanceZone) { //... return angle; }


35


//...}

package example.simulation.math.impl;import example.simulation.math.SimulationMath;import org.osgi.framework.BundleActivator;import org.osgi.framework.BundleContext;import org.osgi.framework.ServiceRegistration;

public class MathActivator implements BundleActivator { SimulatorMath mathImpl = new SimulatorMathService(); ServiceRegistration registration;

public void start(BundleContext bc) throws Exception { registration = bc.registerService( mathImpl.class.getName(), requestResponse, null); }

public void stop(BundleContext bc) throws Exception { registration.unregister(); }}

Manifest-Version:1.0Bnd-LastModified:1516396255825Build-Jdk:9.0.1Built-By: ericjbrunoBundle-Activator: example.simulation.math.MathActivatorBundle-ManifestVersion:2Bundle-Name: mathBundle-SymbolicName: simulation.mathBundle-Version:1.0.0


36


Created-By:Apache Maven Bundle PluginExport-Package: example.simulation.math;version="1.0.0"Import-Package: example.simulation.math;version="[1.0,2)", org.osgi.framework;version="[1.5,2)"Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.6))"Tool:Bnd-3.5.0.20170929184

リストに示したSimulationMath やMyMathImpl からわかるように、OSGiを使う場合、大部分は通常のJavaインタフェースやオブジェクトを使ってコーディングすることになります。注目すべき点は、今回のシンプルな数値

演算ライブラリ・バンドル専用のOSGiバンドル・アクティベータを追加しているところです。OSGiフレームワークは、

MathActivator クラスのインスタンスを作成します。このクラスは、OSGiライフサイクルの命令に従ってバンドルのロードを行い、その実行を開始し、後に停止します。OSGiフレームワークにプラグインするために必要なのは、

バンドル・アクティベータと簡単なマニフェスト・ファイルを追加することだけです。

一連のコンポーネントが動的に組み合わされて管理されるため、安全にシステムを構成してオーケストレー

ションすることができます。それでは、OSGiがJava のモジュール化ソリューションを提供してくれるなら、Java

SE 9 はどこに登場するのでしょうか。

Javaモジュールの概要Java SE 9で導入されたのはモジュール化だけではありませんが、このリリースの目玉は当然 Javaのモジュール化

です。その使用方法は、本誌の以前の号で詳しく解説されています。Java SE 9 にはモジュール機能が組み込まれ

ており、Javaクラス・ライブラリが複数のレイヤーに分割されています。独自のアプリケーションをモジュール化

することもできるようになっています。アプリケーションをモジュールに分割できるようになっているのは、おそら

くアプリケーション間でのモジュール再利用の促進や、将来の拡張性向上のためでしょう。それにより、アプリケー

ションの堅牢性が高まります。JVMによってクラスパスが検証され、コンパイル時にすべての依存性がそろってい

ることが保証されるからです。

アプリケーション・モジュールを定義し、インポートするJavaクラス・ライブラリを指定する作業の一環として、

JVM自体をモジュール化することができます。その結果、アプリケーションで必要なもの以外がすべて取り除か

れたカスタム Javaランタイムが生成され、JVMとアプリケーションの全体的なフットプリントが削減されます。

サイズの観点からすれば、OSGi の場合と同様に、モジュール化はエンタープライズ・アプリケーションにとっ

http://www.oracle.com/webfolder/technetwork/jp/javamagazine/Java-SO17-Modules.pdf


37


て大した争点ではないかもしれません。しかし、現在のビジネ

スで重要なトピックとなっている組込みやIoTの開発の世界では、

サイズが大きな問題になります。

OSGiと同様に、Javaのモジュール・システムでも、アプリケー

ションが依存するモジュールを指定する必要があります（新しい

requires キーワードを使います）。また、他から使用するためにアプリケーション（すなわちモジュール）からエクスポートするモ

ジュールも指定する必要があります（図 3）。OSGiと Java SEのモジュール・システムで異なるのは、その実装です。Javaのモ

ジュール・システムでは、すべての依存性を記述するmodule-

info.javaファイルを定義します。すると、Javaコンパイラによっ

てモジュール化が強制され、すべての依存モジュールがコンパイ

ル時に存在することが検証されます。

リスト2に、図 3に対応するmodule-info.javaファイルを示します。ここでは、同じサンプル・アプリケーションのモジュール化要件を定義しています。このサンプル・

アプリケーションは、ユーザー・インタフェースと数値演算ライブラリの実装から構成されています。

リスト2：2つのサンプル・モジュールのソース・ファイル（1つ目は数値演算用のパッケージ、2つ目はアプリケーションのUI）// simulation.math/module-info.javamodule simulation.math { exports example.simulation.math;}

...

// simulation.ui/module-info.javamodule simulation.ui { requires simulation.math;}

図3：サンプルのシミュレーション・アプリケーションで利用できるJavaモジュールの例


38


比較のため、図 3のJavaモジュール版と同様のアプリケーションの、OSGiにおけるファイル構造を図 4に示します。

次は、ここで説明したOSGiと Java のモジュールの概要を踏まえて、

それぞれの長所と相違点について見ていきます。

OSGiモジュールと Javaモジュールの比較OSGiでは、アプリケーション用のプラグイン・モデルを作成します。そ

の代表的なアプリケーションとして、

Eclipse IDE が挙げられます。OSGi の成功には、コンポーネントの動的

な管理をサポートしている点が大きく影響しています。OSGiでは、プラ

グインまたはコンポーネント（OSGi バンドルとして定義されているモジュー

ル）が動的にロードされ、アクティブ化、非アクティブ化、さらには必要

に応じてアップデートや削除が行われます。現時点において、このように

動的なモジュール・ライフサイクルは、Javaモジュールでは利用できませ

ん。

また、OSGiでは Javaモジュールよりも優れたバージョニングがサポートされています。さらに、OSGiには

独立性に関する長所もあります。たとえば、バンドルを変更した場合、再コンパイルが必要になるのは直接的な

依存性のみです。一方、Javaのモジュールでは、1つのモジュールを変更しただけでも、レイヤー全体（すべての

子レイヤーを含む）を再コンパイルする必要があります（図 5）。Javaモジュールでは、適切なコーディング慣習を強制するため、リフレクションを使っても内部実装（プライ

ベート・クラス）を使用できないような隠蔽が行われています。これは、以前のバージョンのJavaと比較して改

善されています。OSGiでは、その点を強制できません。リフレクションによってOSGi バンドルの内部クラスを

使用できることは、弱点であると見なすこともできます。しかし、それによってプライベート・クラスの依存性注

入を実現できるのも事実です。Javaモジュールの場合、このような依存性注入は不可能ではないにしても、実現

はOSGiよりも困難です。

OSGi バンドルの欠点は、依然としてクラスパス問題の影響を受けることです。たとえば、依存性が見つか

らない場合に実行時例外が発生すること、同じ名前のパッケージが複数ある場合にどのクラスがロードされるか

わからないこと（パッケージの分裂とも呼ばれています）などが挙げられます。さらに、OSGiでは、モジュール

図4：サンプルのシミュレーション・アプリケーションで利用できるOSGi

モジュールの例


39


ごとにクラスローダが必要になります。こ

のことが、単一のクラスローダしか想定

していない一部のライブラリに影響を及

ぼす可能性があります。Javaモジュール

では、パッケージの分裂が起きないよう

になっています。この点は、Java全体に

とって大きな改善だと考えられています。

また、OSGiに存在するような、クラスロー

ダの要件や制限はありません。

OSGiと比較した場合、Javaモジュー

ルの大きな長所は、前述のリスト1で示した、コンパイラのサポートです。JDK

がモジュール化されたため、クラスパス

問題をコンパイル時に明らかにすることができます。また、JDKを使用してカスタムのJVMやランタイムを作成し、

全体のフットプリントやデプロイのサイズを削減することができます。OSGiでは、JVMやライブラリを操作する

ことはできません。

IoTのサポートは、OSGiモジュールと Javaモジュールの両方の長所ですが、その理由は異なります。

■ OSGi は、モジュールのバージョニングとライフサイクルが優れており、インストール、オンとオフ、アップデートや完全な削除をリモートから行うことができます。

■ Javaモジュールでは、カスタムのモジュール式 JDKやJVMを作成し、フットプリントやデプロイのサイズを削減することができます。

IoT、モバイル・アプリケーション、組込み開発のサポートなど、さまざまな分野で、OSGiモジュールと Javaモジュー

ルの併用は理にかなっています。

OSGiモジュールと Javaモジュールの併用前述のように、OSGiモジュールと Javaモジュールは（そのように意図されて設計されていないにしても、）互い

に補完し合うものです。全体的な方向性として、ライブラリ（インポートまたはエクスポートされるもの）と JVM

自体のモジュール化には Javaモジュールを使い、アプリケーションのモジュール化の管理や動的なライフサイク

ル管理にはOSGiを使います。いずれのテクノロジーも、単体で完全なソリューションを提供することはできませ

図5：Javaモジュールのレイヤーおよび依存性では変更が伝播しますが、OSGiでは変更が分離されます

* = updated# = requires rebuild

Application Layer

Layer 2

Layer 1

JPMS Boot Layer

# Desk top UI # Web UI # Mobile UI

# Simulation Engine

Math Module

java.base java.sql java.xml

Depe

nden

cies

Module B API

* Framework


40


んが、その両方を組み合わせることで、

モジュールのサポートを全体に広げること

が可能です（図 6）。既存のJavaアプリケーションをその

まま（既存のコードにモジュールを明示的

に定義せずに）Java 9で実行できるよう

にするため、デフォルトでは、JVMは互換

モードで動作するようになっています。こ

れは、無名モジュールを作成し、そこにモ

ジュールの一部でないアプリケーションの

コードを入れることによって実現されてい

ます。Java SE 9 の互換モードでOSGiが

動作すると、JVMによって、OSGi バンドル、

サービス、実行環境のそれぞれに対して

無名モジュールが自動生成されます。しか

し、明示的な Javaモジュール（互換モー

ドのモジュールではなく、真性のJava 9 モ

ジュールとして設計されたもの）は、無名

モジュールをインポートすることができま

せん。したがって、OSGi バンドルをインポートするためには、アプリケーションと実行環境内のすべてのOSGi バ

ンドルを、対応するJava 9 モジュールにロードする必要があります。これを行うためには、以下のことが必要にな

ります。 ■ バンドルの import をモジュールの requires に一致させます。 ■ バンドル名をモジュール名に一致させます。 ■ バンドルのバージョンをモジュールのバージョンに一致させます。 ■ プライベート・クラスは、すべてからアクセスできるようにしなければならない可能性があります。 ■ グラフ（ノードがモジュールであり、エッジでモジュール間の依存性を定義するもの）におけるバンドルの依存

性ごとに、モジュールのレイヤーを定義する必要があります。Java 9 のレイヤーを使った場合、OSGi バンドル

が、実行中のアプリケーションで新しい実装をロード、起動、停止、さらにはアップデートできるのと同じように、

図6：JPMS上にOSGiを導入すると、モジュール性がアプリケーションからライブラリ、そしてJVM自体にまで拡張され、完全なライフサイクル管理も

実現します

Ser vices

Bund

lesJa

vaMo

dule

Lifecycle

Modules

Secu

rity:

OS, J

ava,

OSGi,

App

OSGi E xecution Environment

Java 9 Vir tual Machine

Java Platform Management System

Operating System

Focus of modularity


41


実行中のアプリケーションに新しいモジュールを追加できます。

2つを併用するメリットとして、以下のような点が挙げられます。 ■ 独立性の向上：Javaプラットフォーム管理システム（JPMS）レイヤー

内の単一のOSGi バンドルを変更しても、再ビルドする際にその

レイヤーや依存するレイヤーを必要としないで済む可能性が高

いと言えます。 ■ Split Package や Circular Dependencyに関するJavaモジュー

ルの制約がバンドルに継承されます。 ■ コンパイル時にすべての依存性が存在しなければならないとい

う、Javaモジュールでの要件がバンドルに継承されます。 ■ 移行：OSGi バンドルの定義や解決は、Javaモジュール上で「そ

のまま」維持されます。 ■ 互換性：OSGi バンドルは、Java SE 8やそれ以前のJVMでも単

独で動作します。

このような仕組みでそれぞれのモジュールを併用するために、先ほ

どの例に含まれる、Javaのmath モジュールのコードで、先ほど構築したOSGi のmath バンドルを拡張します。

OSGi バンドルのコードのパッケージ名は、少しだけ変更する必要があります。その結果、両方が組み合わされた

ディレクトリ構造ができあがります。この構造を図7に示します。

リスト3のコードには、mathモジュールの2つの実装が含まれています。実際の実装はOSGiバンドルであり、

JavaモジュールはOSGi バンドルを拡張しているだけです。

リスト3：OSGi のmathバンドルと Javaのmathモジュールの併用package osgi.simulation.math.impl;import osgi.simulation.math.SimulationMath;public class MyMathImpl implements SimulationMath { // 実際の実装をここに記述 ...}

package example.simulation.math;

図7：Javaモジュールsimulation.mathは、OSGiのmathバンドル実装を拡張しています


42


//// OSGi バンドルを拡張した JPMSモジュール //public class MyMathImpl extends osgi.simulation.math.impl.MyMathImpl {}

Javaモジュールのサンプル・アプリケーションに含まれているコンパイル・スクリプトは、わずかに変更する必要

があります。具体的には、更新したモジュールのソース・パスとOSGi のmathバンドル・ファイルへのパスをクラ

スパスに含めます。

javac -d out -classpath ./math/target/*.jar --module-source-path ./math/src -m simulation.math

アプリケーション・レイヤーは、OSGi バンドルをラップする、Javaモジュールのラッパーをロードしているだけで

あるため、モジュール性はそのまま維持されます。

まとめ協力は、競争に勝ります。JavaモジュールとOSGiを組み合わせれば、それぞれを単体で使った場合とは異なり、完全でより堅牢なモジュール化ソリューションを実現できます。たとえば、Javaモジュールを使わずにOSGiだけを使った場合、コンパイル時における依存性の強制をサポートすることはできません。同じように、OSGiを使わなかった場合、アプリケーションレベルのモジュール性は完全ではなく、ライフサイクル管理もそれほど堅牢ではありません。

両方を組み合わせることで、ますます数が増えているJava 9 モジュールを既存のOSGiアプリケーションで

利用しやすくもなります。また、OSGi のバンドルやサービスをJava 9アプリケーションに組み入れるためのクリー

ンな統合（移行と言うこともできるかもしれません）パスも実現します。

本記事の締めくくりとして、筆者の考えを書いておきます。コンピュータ・サイエンスにおいて対立するコンセ

プト（OS戦争、C++対 Javaの議論、フレームワークの違いなど）が登場したときは、一方を妄信することは避け、

両者を協調させる方法を探る方が、大抵の場合はうまくいきます。</article>

Eric J. Bruno：Perrone Roboticsでリアルタイム・エンジニアのリーダーを務め、自動運転車技術の開発を行う。大規模分散ソフトウェアの設計を専門とするエンタープライズ・アーキテクト、開発者、アナリストであり、25年にわたって情報テクノロジー・コミュニティで活躍している。

osgiモジュールとjava 9モジュール の連携 - oracle...装、internet of...

Documents

osgiモジュールとjava 9モジュールの連携 - oracle...装、internet of...