ネイティブ・ライブラリーは、.dll、.so などのプラットフォーム固有のライブラリー・ファイル、または
*SRVPGM オブジェクトであり、共有ライブラリー内で構成することができます。
ネイティブ・ライブラリーは、共有ライブラリーがアプリケーションに関連付けられている場合、
常にそのアプリケーション・クラス・ローダーに対して可視です。
同様に、共有ライブラリーがアプリケーション・サーバーに関連付けられている場合、ネイティブ・ライブラリーは、
そのアプリケーション・サーバーのクラス・ローダーに対して可視です。
始める前に
共有ライブラリーの設計では、Java ネイティブ・ライブラリーのサポートについて、次の条件を考慮します。
- Java 仮想マシン (JVM) は、特定のネイティブ・ライブラリーをロードするのに 1 つのクラス・ローダーのみを許可します。
- クラス・ローダーからネイティブ・ライブラリーをアンロードするアプリケーション・プログラミング・インターフェース (API) はありません。
ネイティブ・ライブラリーは、
そのライブラリーを検出したクラス・ローダーがガーベッジ・コレクションでヒープから収集されるときに、JVM によってアンロードされます。
- アプリケーション・サーバーのクラス・ローダーは、ネイティブの JVM クラス・ローダーと異なり、
現行プラットフォーム用のデフォルトのオペレーティング・システム拡張を使用するネイティブの共有ライブラリーのみをロードします。
例えば AIX の場合、アプリケーション・サーバーのクラス・ローダーによるロード時にはネイティブの共有ライブラリーの末尾は .a である必要があります。
JVM クラス・ローダーでは、末尾が .a または .so であるファイルをロードします。
Java Web Start が
ロードできるのは、ファイル拡張子が .so の、ネイティブの共有ライブラリーのみです。ネイティブの共有ライブラリーの名前
を .so ファイル拡張子になるように変更してから、Java Web Start でのデプロイ用に、それらのライブラリー
を 1 つの Java アーカイブ (JAR) ファイルにパッケージしてください。
- アプリケーション・サーバーのクラス・ローダーは、アプリケーション・サーバーが継続している間は持続します。
- アプリケーションのクラス・ローダーは、アプリケーションが停止するか、または動的に再ロードされるまで持続します。
ネイティブ・ライブラリー・パスで構成された共有ライブラリーが
アプリケーションに関連付けられている場合、アプリケーションは、再始動されるか、
または動的に再ロードされると、UnsatisfiedLinkError で失敗する場合があ
ります。このエラーは、ライブラリーが既にロードされていることを示します。
このエラーが発生するのは、アプリケーションが、再始動するときに、
ネイティブ・ライブラリーを再ロードする共有ライブラリー・クラスを呼び出すためです。
しかし、ネイティブ・ライブラリーは、先にネイティブ・ライブラリーをロードした
アプリケーションのクラス・ローダーがガーベッジ・コレクションで収集されていないので、まだメモリーにロードされた状態のままです。
- 従属ネイティブ・ライブラリーをロードできるのは、JVM クラス・ローダーのみです。
例えば、
NativeLib1 が NativeLib2 に従属する場合、NativeLib2 は、JVM クラス・ローダーから可視である必要があります。LIBPATH 環境変数によって定義されている Java ライブラリー・パスで、NativeLib2
を含むパスが指定されている必要があります。
LIBPATH (java.library.path) プロパティーは、
process_name_region_libpath 環境変数 (control_region_libpath、
server_region_libpath、adjunct_region_libpath など) を使用して
構成されます。領域の LIBPATH 変数の設定方法については、
BBOM0001I メッセージで参照される変数の値の変更を参照してください。
共有ライブラリー内で構成される
ネイティブ・ライブラリーが、他のネイティブ・ライブラリーに従属する場合、
その従属ライブラリーが正常にロードされるためには、
従属ライブラリーが、アプリケーション・サーバーをホストする JVM の LIBPATH に構成されている必要があります。
このタスクについて
共有ライブラリーの設定ページで共有ライブラリーを構成する際、
「ネイティブ・ライブラリー・パス (Native library path)」に値を指定しても、このパス上のネイティブ・ライブラリーは、このネイティブ・ライブラリーをロードするクラス自体が同じクラス・ローダーによってロードされていない限り、
WebSphere® Application Server アプリケーション
または共有ライブラリーのクラス・ローダーからは見つけられません。
ネイティブ・ライブラリーは、1 つのクラス・ローダーによって複数回ロードすることができないので、
アプリケーション・サーバーの
クラス・ローダーに関連付けられた共有ライブラリー内でネイティブ・ライブラリーをロードする方が適切と言えます。
これは、これらのクラス・ローダーがサーバーの存続期間中は持続するためです。
手順
- ネイティブ・ライブラリーをロードするクラスの静的メソッドを実装します。
ネイティブ・ライブラリーをロードするクラスの
静的ブロックで System.loadLibrary(native_library) を呼び出します。以下に例を示します。
static {System.loadLibrary("native_library");
native_library は、クラスの静的初期化の間にロードされます。初期化は、クラスがロードされるときに 1 回だけ行われます。
- 共有ライブラリーの設定
ページで、共有ライブラリーがネイティブ・ライブラリーをロードするための
「クラスパス (Classpath)」、および「ネイティブ・ライブラリー・パス (Native library path)」の値を設定します。
共有ライブラリーを
アプリケーションまたはモジュールに関連付ける場合は、「この共有ライブラリーに
独立したクラス・ローダーを使用 (Use an isolated class loader for this shared library)」を選択します。この設定を使用可能にしない場合は、
共有ライブラリーをアプリケーション・サーバーに関連付けます。
- 共有ライブラリーを関連付けます。
- 「この共有ライブラリーに独立したクラス・ローダーを使用 (Use an isolated class loader for this shared library)」を使用可能にしなかった場合は、
共有ライブラリーを
アプリケーション・サーバーに関連付けます。
共有ライブラリーを、アプリケーションではなく、アプリケーション・サーバーのクラス・ローダーに関連付けることにより、
サーバー上でアプリケーションが再始動、または動的に再ロードされても、共有ライブラリーのロードは、必ず、
アプリケーション・サーバーのクラス・ローダーによる 1 回のみです。ネイティブ・ライブラリーは静的ブロック内でロードされるため、
そのネイティブ・ライブラリーが複数回ロードされることはありません。
- 「この共有ライブラリーに独立したクラス・ローダーを使用 (Use an isolated class loader for this shared library)」を使用可能にした場合は、共有ライブラリーをアプリケーションまたはモジュールに関連付けます。
独立した共有ライブラリー・ファイルを
アプリケーションまたはモジュールに関連付けると、共有ライブラリーで表されるクラスが、
この共有ライブラリー用に作成された別のクラス・ローダーにロードされます。共有ライブラリー用に別のクラス・ローダーを用意する場合は、
独立した共有ライブラリー・ファイルをサーバーに関連付けないでください。共有ライブラリーを
サーバーに関連付けると、独立の設定は無視され、
共有ライブラリーのファイルがアプリケーション・サーバー・クラス・ローダーに追加されます。したがって、
独立した共有ライブラリー・ファイルをサーバーに関連付けると、
そのファイルがサーバー上のすべてのアプリケーションに関連付けられます。
独立した
共有ライブラリー用に作成されたクラス・ローダーは、再ロードを行わず、
サーバー・クラス・ローダーのように、サーバーの存続時間の間存在します。共有ネイティブ・ライブラリーの場合、
独立した共有ライブラリーを使用して、ネイティブ・ライブラリーの再ロードから生じる
エラーを回避することができます。
次のタスク
アプリケーションが共有ライブラリーを使用できることを検証するには、
アプリケーションをテストするか、Class loader viewer でクラス・ローダーを調べます。とクリックします。アプリケーション・モジュール・クラス・ローダーのクラスパスは、共有ライブラリーによって使用されたクラスをリストします。