「Javaクラスローダー」の版間の差分
削除された内容 追加された内容
Luckas-bot (会話 | 投稿記録) m r2.7.1) (ロボットによる 追加: uk:Java Classloader |
en:Java Classloader(21:11, 31 January 2012 UTC)より「JAR地獄」の節を翻訳 |
||
72行目:
| date=2002-08-21
| accessdate=2008-01-26}} </ref>
== JAR地獄 ==
[[DLL地獄]]に似た言葉として'''JAR地獄'''という言葉があるが、これはクラスのロードが思ったとおりに行われない状況全般を指して使われる<ref>http://incubator.apache.org/depot/version/jar-hell.html</ref>。
JAR地獄の発生する状況としては次の3つがある。
* 一つ目は、Javaアプリケーションの開発や配置の際に、たまたま同じライブラリの2つのバージョンが同時に利用可能になってしまった場合である。この場合、処理系はエラーを発生させず、単純にどちらか一方のライブラリからのみクラスをロードする。使用するライブラリのリストに新しいライブラリを追加（置き換えではなく）した場合、アプリケーションは古いライブラリを使っているのと同じ振る舞いになるものと考えられる。
* 問題が発生するもう一つの状況は、2つのライブラリAとB（または、アプリケーションAとそれが使っているライブラリB）が、別のライブラリCの異なるバージョンをそれぞれ要求している場合である。 ライブラリCの各バージョンでクラス名が変わらないなら、ライブラリCの各バージョンを一つのクラスローダで同時にロードする方法は存在しない。
* JAR地獄で最も複雑な問題は、クラスローダーの複雑性によって発生する。Javaプログラムでは単一の「フラットな」クラスローダーだけでなく、ネストした、協調して動作する複数の（場合によっては非常に多くの）クラスローダーを使用できる。別々のクラスローダーによってロードされたクラスは複雑に相互作用するが、開発者がその機序を十分に理解していない場合、不可解なエラーやバグが発生する<ref>http://www.ibm.com/developerworks/jp/websphere/library/java/j2ee_classloader/2.html#N10118</ref>。
[[OSGi]]アライアンスは、現在および将来において、広く利用されているJavaME, SE, EEの各VMでJAR地獄を解決するべく、モジュール方式のフレームワークを策定している（1998年のJSR 8から始まっている）。これは、JAR [[manifestファイル|manifest]]中に書かれたメタデータを使い、JARファイル（''バンドル''と呼ばれる）をパッケージ単位で操作するものである。バンドルはパッケージをエクスポートしたりインポートしたり、パッケージをプライベートに保っておいたりすることができ、これにより基本的なモジュール化と、バージョン付けされた依存関係管理が行える。
JAR地獄に対する改善策として、2005年に[[Java Community Process]]によるJSR 277の策定が始まり、その結果として[[Java Module System]]が定義された。これは、配布フォーマット、モジュールのバージョン体系、共通モジュールのリポジトリ（目的は[[.NET Framework]]の[[Global Assembly Cache]]に類似）をJavaに導入することを目的としていたが、2008年12月、SunはJSR 277を保留とすることを発表した<ref>http://www.osgi.org/News/20081217</ref>。
==関連項目==
78 ⟶ 92行目:
* [[DLL地獄]]
* [[OSGi]]
* [[Apache Maven]]
==参考文献==
| |||