Javaクラスローダー

Javaクラスローダー（）とは、Java仮想マシン (Java VM; JVM) の一部で、JavaクラスをJava仮想マシンに動的にロードする役割を持つ。通常、クラスは必要になったとき初めてロードされる。Javaの実行系は、クラスローダーがあるおかげでファイルやファイルシステムについて知る必要がない。クラスローダーについて学習する場合には、この委譲が重要な考え方である。
ソフトウェアのライブラリとは、オブジェクトコードと多かれ少なかれ関連しているが、Java言語ではライブラリはJARファイルに格納され、様々なオブジェクトを格納することができる。クラスはコードに名前をつけた一つの単位であり、クラスローダーはライブラリを見つけて内容をロードし、ライブラリに含まれるクラスをロードする責務を持つ。クラスのロードは「必要に応じて」であり、すなわちクラスがプログラムにおいて実際に必要になるまで行われない。指定された名称（パッケージ名を含む完全名）のクラスは、あるクラスローダーにたった一度だけしかロードされないが、参照されなくなったクラスがアンロードされることや、再度ロードされることもある。詳細はSingleton パターン#Javaでの実装例を参照のこと。
クラスロードのプロセス.
各Javaクラスは、クラスローダーによってロードされなければならない。さらに、Javaプログラムは外部ライブラリ（つまり、プログラムの作者とは別の誰かが開発し提供するライブラリ）を利用する可能性もあり、また、それ自身が複数のライブラリで構成されている場合もある。
JVMが開始されると、:
ブートストラップクラスローダーは、中核のJavaライブラリを codice_1 ディレクトリからロードする。このクラスローダーはJavaVMの中心部分であり、ネイティブコードで記述されている。
拡張クラスローダーは、拡張ディレクトリ (codice_2 や、codice_3プロパティで指定された他のディレクトリ) にあるコードをロードする。これは、codice_4 クラスで実装されている。
システムクラスローダーは、codice_5、すなわちシステム環境変数 codice_6 にあるクラスをロードする。こちらは、codice_7 クラスで実装されている。
ユーザー定義のクラスローダー.
既定では、ユーザーのクラスは全てシステムクラスローダーからロードされるが、ユーザーが定義した に置き換えたり、さらにクラスローダーの連結構造をユーザー定義したり、といったこともできる。
これにより、たとえば以下のようなことが可能になる:
Jakarta EEにおけるクラスローダー.
Jakarta EE (旧・Java EE) のアプリケーションサーバーは、通例サーバーに配置されたWARやEARアーカイブを階層的に配置されたクラスローダーでロードして、アプリケーション同士を隔離している。
いわゆる"サーブレットコンテナ"は、通例複数のクラスローダーを用いて実装されている。
JAR地獄.
DLL地獄に似た言葉としてJAR地獄という言葉があるが、これはクラスのロードが思ったとおりに行われない状況全般を指して使われる。
JAR地獄の発生する状況としては次の3つがある。
OSGiアライアンスは、現在および将来において、広く利用されているJava ME、Java SE、Jakarta EEの各VMでJAR地獄を解決するべく、モジュール方式のフレームワークを策定している（1998年のJSR 8から始まっている）。これは、中に書かれたメタデータを使い、JARファイル（"バンドル"と呼ばれる）をパッケージ単位で操作するものである。バンドルはパッケージをエクスポートしたりインポートしたり、パッケージをプライベートに保っておいたりすることができ、これにより基本的なモジュール化と、バージョン付けされた依存関係管理が行える。
JAR地獄に対する改善策として、2005年にJava Community ProcessによるJSR 277の策定が始まり、その結果として「Java Module System」が定義された。これは、配布フォーマット、モジュールのバージョン体系、共通モジュールのリポジトリ（目的は.NET FrameworkのGlobal Assembly Cacheに類似）をJavaに導入することを目的としていたが、バージョニングの問題などで論争が起き、2008年12月、SunはJSR 277を保留とすることを発表した。その後、後継となるJSR 376のとしてJava 9で正式に導入された。