Javaクラスローダー
 | この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。（2021年6月） |
Javaクラスローダー（英: Java class loader）とは、Java仮想マシン (Java VM; JVM) の一部で、JavaクラスをJava仮想マシンに動的にロードする役割を持つ[1]。通常、クラスは必要になったとき初めてロードされる。Javaの実行系は、クラスローダーがあるおかげでファイルやファイルシステムについて知る必要がない。クラスローダーについて学習する場合には、この委譲が重要な考え方である。
ソフトウェアのライブラリとは、オブジェクトコードと多かれ少なかれ関連しているが、Java言語ではライブラリはJARファイルに格納され、様々なオブジェクトを格納することができる。クラスはコードに名前をつけた一つの単位であり、クラスローダーはライブラリを見つけて内容をロードし、ライブラリに含まれるクラスをロードする責務を持つ。クラスのロードは「必要に応じて」であり、すなわちクラスがプログラムにおいて実際に必要になるまで行われない。指定された名称（パッケージ名を含む完全名）のクラスは、あるクラスローダーにたった一度だけしかロードされないが、参照されなくなったクラスがアンロードされることや、再度ロードされることもある。詳細はSingleton パターン#Javaでの実装例を参照のこと。
クラスロードのプロセス
各Javaクラスは、クラスローダーによってロードされなければならない[2]。さらに、Javaプログラムは外部ライブラリ（つまり、プログラムの作者とは別の誰かが開発し提供するライブラリ）を利用する可能性もあり、また、それ自身が複数のライブラリで構成されている場合もある。
JVMが開始されると、3つのクラスローダーが使用される[要検証][3][4]:
- ブートストラップクラスローダー (bootstrap class loader)
- 拡張クラスローダー (extension class loader)
- システムクラスローダー (system class loader)
ブートストラップクラスローダーは、中核のJavaライブラリを <JAVA_HOME>/lib ディレクトリからロードする[注釈 1]。このクラスローダーはJavaVMの中心部分であり、ネイティブコードで記述されている。
拡張クラスローダーは、拡張ディレクトリ (<JAVA_HOME>/lib/ext や、java.ext.dirsプロパティで指定された他のディレクトリ) にあるコードをロードする。これは、sun.misc.Launcher$ExtClassLoader クラスで実装されている。
システムクラスローダーは、java.class.path、すなわちシステム環境変数 CLASSPATH にあるクラスをロードする。こちらは、sun.misc.Launcher$AppClassLoader クラスで実装されている。
ユーザー定義のクラスローダー
既定では、ユーザーのクラスは全てシステムクラスローダーからロードされるが、ユーザーが定義した ClassLoader に置き換えたり、さらにクラスローダーの連結構造をユーザー定義したり、といったこともできる。
これにより、たとえば以下のようなことが可能になる:
- クラスのロード・アンロードを実行時に行う。たとえば、実行時にHTTPリソースからライブラリを動的にロードするなど。これは以下の用途において重要な機能である:
- 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]
脚注
注釈
- ^ core.jar、server.jar、rt.jarなどのJARファイルに格納されている。
出典
- ^ Binildas, Mcmanis (1996年1月10日). “The basics of Java class loaders”. JavaWorld. 2008年1月26日閲覧。[リンク切れ]
- ^ a b Binildas, Christudas (2005年1月26日). “Internals of Java Class Loading”. onjava.com. 2009年10月2日閲覧。[リンク切れ]
- ^ “Understanding Extension Class Loading”. java.sun.com (2008年2月14日). 2008年1月26日閲覧。
- ^ Dennis, Sosnoski (2003年4月29日). “Classes and class loading”. ibm.com. 2008年1月26日閲覧。[リンク切れ]
- ^ Vladimir, Roubtsov (2003年9月5日). “Cracking Java byte-code encryption”. javaworld.com. 2008年1月26日閲覧。[リンク切れ]
- ^ Tim, deBoer (2002年8月21日). “J2EE Class Loading Demystified”. ibm.com. 2008年1月26日閲覧。[リンク切れ]
- ^ http://incubator.apache.org/depot/version/jar-hell.html[リンク切れ]
- ^ クラスローダーとJ2EEパッケージング戦略を理解する: 第2回「クラスローダーを理解する - シングルトンがシングルトンでなくなる日」| IBM, Internet Archive
- ^ JSR 277論争、バージョニングで再燃 | InfoQ
- ^ http://www.osgi.org/News/20081217[リンク切れ]
- ^ イマドキのJava徹底入門(4) Javaのモジュールシステムを理解しよう（その1） | TECH+
- ^ Bartlett, Neil; Hackbarth, Kai (2016年9月22日). “Java 9, OSGi and the Future of Modularity (Part 1)”. 2024年2月25日閲覧。
関連項目
- JAR (ファイルフォーマット)
- ローダ
- 動的ロード
- DLL地獄
- OSGi
- Apache Maven
外部リンク
 | この節には参考文献や外部リンクの一覧が含まれていますが、脚注による参照が不十分であるため、情報源が依然不明確です。 |
 | ウィキペディアはオンライン百科事典であって、情報を無差別に収集する場ではありません。 |
- Article "Java Class Loading: The Basics" by Brandon E. Taylor
- Article "Take Control of Class Loading in Java" by Jeff Hanson
- Article "Inside Class Loaders" by Andreas Schaefer
- Article "Dynamic class loading in the Java virtual machine" by Sheng Liang and Gilad Bracha
- Article "Real-World Use For Custom ClassLoaders" by Jeremy Whitlock
- Article "Classloaders Revisited Hotdeploy" by Dr. Christoph G. Jung in Java Specialist Newsletter
- Article "Managing Component Dependencies Using ClassLoaders" by Don Schwarz
- Dependency manager - now at Apache incubator
- Dynamically loading classes directly from JAR files
- Free Maven Book
- ClassWorlds
- JarJar
- One-Jar
- Spring Dynamic Modules for OSGi(tm) Service Platforms
- POMStrap
- CollectionSpy — A Java profiler that includes a class loading log view and graph
「Java Classloader」の例文・使い方・用例・文例
- Java Classloaderのページへのリンク
