Javaクラスローダー

ウィキペディア

索引トップ用語の索引ランキングカテゴリー

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2024/02/25 00:16 UTC 版)

ユーザー定義のクラスローダー

既定では、ユーザーのクラスは全てシステムクラスローダーからロードされるが、ユーザーが定義した ClassLoader に置き換えたり、さらにクラスローダーの連結構造をユーザー定義したり、といったこともできる。

これにより、たとえば以下のようなことが可能になる:

クラスのロード・アンロードを実行時に行う。たとえば、実行時にHTTPリソースからライブラリを動的にロードするなど。これは以下の用途において重要な機能である:
- スクリプト言語（動的プログラミング言語）の実装。たとえばJythonやGroovyなど。
- JavaBeansビルダーの利用。
- ユーザー定義の拡張性 (拡張機能) を可能にする。
- 複数の名前空間の間でのやりとりを可能にする。これは、CORBA / RMIの基礎となっている。
Javaバイトコードがロードされる方法を変える (たとえば、暗号化されたJavaクラスをロードする^[5])。
ロード済みのバイトコードを改変する (たとえば、アスペクト指向プログラミングで用いれば、ロード時の織り込み)。

Jakarta EEにおけるクラスローダー

Jakarta EE (旧・Java EE) のアプリケーションサーバーは、通例サーバーに配置されたWARやEARアーカイブを階層的に配置されたクラスローダーでロードして、アプリケーション同士を隔離している。いわゆる"サーブレットコンテナ"は、通例複数のクラスローダーを用いて実装されている^[2]^[6]。

JAR地獄

DLL地獄に似た言葉としてJAR地獄という言葉があるが、これはクラスのロードが思ったとおりに行われない状況全般を指して使われる^[7]。

JAR地獄の発生する状況としては次の3つがある。

一つ目は、Javaアプリケーションの開発や配置の際に、たまたま同じライブラリの複数のバージョンが同時に利用可能になってしまった場合である。この場合、処理系はエラーを発生させず、単純にどちらか一方のライブラリからのみクラスをロードする。使用するライブラリのリストに新しいライブラリを追加（置き換えではなく）した場合、アプリケーションは古いライブラリを使っているのと同じ振る舞いになるものと考えられる。

問題が発生するもう一つの状況は、2つのライブラリAとB（または、アプリケーションAとそれが使っているライブラリB）が、別のライブラリCの異なるバージョンをそれぞれ要求している場合である。ライブラリCの各バージョンでクラス名が変わらないなら、ライブラリCの各バージョンを一つのクラスローダーで同時にロードする方法は存在しない。

JAR地獄で最も複雑な問題は、クラスローダーの複雑性によって発生する。Javaプログラムでは単一の「フラットな」クラスローダーだけでなく、ネストした、協調して動作する複数の（場合によっては非常に多くの）クラスローダーを使用できる。別々のクラスローダーによってロードされたクラスは複雑に相互作用するが、開発者がその機序を十分に理解していない場合、不可解なエラーやバグが発生する^[8]。

OSGiアライアンスは、現在および将来において、広く利用されているJava ME、Java SE、Jakarta EEの各VMでJAR地獄を解決するべく、モジュール方式のフレームワークを策定している（1998年のJSR 8から始まっている）。これは、JARマニフェスト（英語版）中に書かれたメタデータを使い、JARファイル（バンドルと呼ばれる）をパッケージ単位で操作するものである。バンドルはパッケージをエクスポートしたりインポートしたり、パッケージをプライベートに保っておいたりすることができ、これにより基本的なモジュール化と、バージョン付けされた依存関係管理が行える。

JAR地獄に対する改善策として、2005年にJava Community ProcessによるJSR 277の策定が始まり、その結果として「Java Module System」が定義された。これは、配布フォーマット、モジュールのバージョン体系、共通モジュールのリポジトリ（目的は.NET FrameworkのGlobal Assembly Cacheに類似）をJavaに導入することを目的としていたが、バージョニングの問題などで論争が起き^[9]、2008年12月、SunはJSR 277を保留とすることを発表した^[10]。その後、後継となるJSR 376のJavaプラットフォームモジュールシステム（英語版）としてJava 9で正式に導入された^[11]。2017年にリリースされたJava 9には、「Java Platform Module System」と呼ばれるモジュール型ソフトウェアのサポートが含まれており、module-info.javaファイルによってソースレベルで制御される。下位互換性のある方法でJava ランタイム環境にモジュール性を提供することを目的とした OSGi アーキテクチャとは異なる哲学に従っており、JRE が提供するクラスをロードするデフォルトのメカニズムを使用する。しかし異なるバージョンのライブラリの共存を制御する機能は提供しないため、JAR地獄問題への取り組みには適していない。^[12]