JAR地獄
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/06/11 16:17 UTC 版)
「Javaクラスローダー」の記事における「JAR地獄」の解説
DLL地獄に似た言葉としてJAR地獄という言葉があるが、これはクラスのロードが思ったとおりに行われない状況全般を指して使われる。 JAR地獄の発生する状況としては次の3つがある。 一つ目は、Javaアプリケーションの開発や配置の際に、たまたま同じライブラリの2つのバージョンが同時に利用可能になってしまった場合である。この場合、処理系はエラーを発生させず、単純にどちらか一方のライブラリからのみクラスをロードする。使用するライブラリのリストに新しいライブラリを追加（置き換えではなく）した場合、アプリケーションは古いライブラリを使っているのと同じ振る舞いになるものと考えられる。 問題が発生するもう一つの状況は、2つのライブラリAとB（または、アプリケーションAとそれが使っているライブラリB）が、別のライブラリCの異なるバージョンをそれぞれ要求している場合である。 ライブラリCの各バージョンでクラス名が変わらないなら、ライブラリCの各バージョンを一つのクラスローダーで同時にロードする方法は存在しない。 JAR地獄で最も複雑な問題は、クラスローダーの複雑性によって発生する。Javaプログラムでは単一の「フラットな」クラスローダーだけでなく、ネストした、協調して動作する複数の（場合によっては非常に多くの）クラスローダーを使用できる。別々のクラスローダーによってロードされたクラスは複雑に相互作用するが、開発者がその機序を十分に理解していない場合、不可解なエラーやバグが発生する。 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に導入することを目的としていたが、2008年12月、SunはJSR 277を保留とすることを発表した。
※この「JAR地獄」の解説は、「Javaクラスローダー」の解説の一部です。
「JAR地獄」を含む「Javaクラスローダー」の記事については、「Javaクラスローダー」の概要を参照ください。
- JAR地獄のページへのリンク
