Java クラスローダー

JavaクラスローダーはJava Runtime Environmentの一部であり、Javaクラスを Java仮想マシンに動的にロードします。^[1]通常、クラスは要求に応じてのみロードされます。仮想マシンはプログラムの実行に必要なクラスファイルのみをロードします。^[2] Javaランタイムシステムはファイルとファイルシステムについて知る必要はなく、これはクラスローダーに委任されます。

ソフトウェアライブラリは、関連するオブジェクトコードの集合です。Java言語では、ライブラリは通常JAR ファイルにパッケージ化されます。ライブラリには、さまざまな種類のオブジェクトを含めることができます。JAR ファイルに含まれる最も重要な種類のオブジェクトは、Java クラスです。クラスは、名前付きのコード単位と考えることができます。クラスローダーは、ライブラリの検索、その内容の読み取り、ライブラリ内に含まれるクラスのロードを担当します。このロードは通常、「オンデマンド」で行われ、クラスがプログラムによって呼び出されるまで実行されません。特定の名前のクラスは、特定のクラスローダーによって 1 回だけロードできます。

各Javaクラスはクラスローダーによってロードされる必要があります。^[3]^[4]さらに、Javaプログラムは外部ライブラリ（つまり、プログラムの作成者以外の誰かが作成して提供したライブラリ）を使用することも、少なくとも部分的に複数のライブラリで構成されることもあります。

JVMが起動すると、3つのクラスローダーが使用されます: ^[5]^[6]^[2]

ブートストラップクラスローダー
拡張クラスローダー
システムクラスローダー

ブートストラップクラスローダーは、（Java 9以降の場合は）ディレクトリにあるコアJavaライブラリ^{[fn 1]}をロードします。このクラスローダーはコアJVMの一部であり、ネイティブコードで記述されています。ブートストラップクラスローダーは、どのオブジェクトにも関連付けられていません。 ^[2]たとえば、はを返します。^[2]<JAVA_HOME>/jre/lib<JAVA_HOME>/jmods>ClassLoaderStringBuilder.class.getClassLoader()null

<JAVA_HOME>/jre/lib/ext拡張クラスローダーは、拡張ディレクトリ（、^[5]またはシステムプロパティで指定されたその他のディレクトリ）内のコードをロードしますjava.ext.dirs。

システムクラスローダーは、にあるコードをロードします。このコードは環境変数java.class.pathにマップされます。 CLASSPATH

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

Java クラスローダーは Java で記述されています。そのため、Java 仮想マシンの詳細を理解していなくても、カスタムクラスローダーを作成できます。Bootstrap クラスローダーを除き、すべての Java クラスローダーには親クラスローダーがあります。^[7]親クラスローダーは、新しいクラスローダーがインスタンス化されるか、仮想マシンのシステムデフォルトクラスローダーに設定されるときに定義されます。

これにより、次のことが可能になります (例):

実行時にクラスをロードまたはアンロードします (たとえば、HTTPリソースからでも実行時にライブラリを動的にロードします)。これは次の場合に重要な機能です。
- Jythonなどのスクリプト言語の実装
- Beanビルダーの使用
- ユーザー定義の拡張性を可能にする
- 複数の名前空間が通信できるようにします。これは、たとえばCORBA / RMIプロトコルの基礎の 1 つです。
バイトコードのロード方法を変更する（例えば、暗号化されたJavaクラスバイトコード^[8]を使用することも可能）。
ロードされたバイトコードを変更する (たとえば、アスペクト指向プログラミングを使用する場合のアスペクトのロード時のウィービング)。

Jakarta EE のクラスローダー

Jakarta EE (旧称 Java EE および J2EE) アプリケーションサーバーは、通常、クラスローダーのツリーによってデプロイされたWARまたはEARアーカイブからクラスをロードし、アプリケーションを他のアプリケーションから分離しますが、デプロイされたモジュール間でクラスを共有します。いわゆる「サーブレットコンテナー」は、通常、複数のクラスローダーによって実装されます。^[4]^[9]

JAR地獄

JAR 地獄はDLL 地獄に似た用語で、クラスローディングプロセスが機能しなくなるさまざまな状況を説明するために使用されます。^[10] JAR 地獄が発生する可能性がある 3 つの状況は次のとおりです。

システムにライブラリの 2 つの異なるバージョンが誤ってインストールされている場合。これはシステムによってエラーとはみなされません。むしろ、システムはどちらかのライブラリからクラスをロードします。新しいライブラリを置き換えるのではなく、使用可能なライブラリのリストに追加すると、アプリケーションは古いライブラリが使用されているかのように動作する可能性があります。実際、古いライブラリが使用されている可能性があります。
複数のライブラリまたはアプリケーションには、ライブラリfooの異なるバージョンが必要です。ライブラリfooのバージョンが同じクラス名を使用する場合、同じクラスローダーを使用してライブラリfooのバージョンをロードする方法はありません。
最も複雑な JAR 地獄問題は、クラスローディングシステムの複雑さをフルに利用した状況で発生します。Java プログラムは、単一の「フラット」なクラスローダーのみを使用する必要はなく、代わりに複数の (場合によっては非常に多数の) ネストされた連携するクラスローダーで構成される場合があります。異なるクラスローダーによってロードされたクラスは、開発者が完全に理解できない複雑な方法で相互作用し、分析、説明、解決が困難なエラーやバグにつながる可能性があります。^[11]

OSGi Alliance は、ME、SE、EE の現在および将来の VM の JAR 地獄を解決することを目的としたモジュール性フレームワークを指定しました (1998 年に JSR 8 として開始)。このフレームワークは広く採用されています。JARマニフェストのメタデータを使用して、JAR ファイル (バンドルと呼ばれる) はパッケージごとに接続されます。バンドルはパッケージをエクスポート、インポートし、パッケージを非公開にすることができ、モジュール性とバージョン管理された依存関係管理の基本構造を提供します。

Java 9では、2017年にJava Platform Module Systemが導入されました。これは、Javaコードと関連リソースのコレクションの配布形式を規定しています。また、これらのコレクション、つまりモジュールを格納するためのリポジトリも規定し、それらを検出、ロード、整合性をチェックする方法も規定しています。既存のJAR形式の欠点のいくつかを修正することを目的として、名前空間などの機能が含まれています。Java Platform Module Systemは、JREが提供するクラスのロードのデフォルトメカニズムを使用して、下位互換性のある方法でJava Runtime Environmentのモジュール性を提供することを目的としたOSGiアーキテクチャとは異なる哲学に従っています。ただし、Java Platform Module Systemは、異なるバージョンのライブラリを制御された共存させる機能を提供しないため、JARヘル問題に完全には対処していません。^[12]

参照

脚注

^これらのライブラリは 、rt.jar、core.jar、server.jarなどと呼ばれるJar ファイルに保存されます。

参考文献

^ Mcmanis, Chuck (1996 年 10 月 1 日). 「Java クラスローダーの基礎」. JavaWorld . 2020 年 7 月 13 日閲覧。
^ abcd Horstmann 2022、§10.1.1 クラスロードプロセス。
^ Horstmann 2022、§8.2.5 バイトコードのメモリへの書き込み。
^ ab Christudas, Binildas (2005 年 1 月 26 日). 「Java クラスローディングの内部」onjava.com . 2018 年 5 月 10 日時点のオリジナルよりアーカイブ。
^ ab 「拡張クラスのロードについて」。Java チュートリアル。docs.oracle.com。2020年7 月 13 日閲覧。
^ Sosnoski, Dennis (2003 年 4 月 29 日)。「クラスとクラスローディング」。IBM DeveloperWorks。2008年 1 月 26 日閲覧。
^ Horstmann 2022、10.1.2 クラスローダー階層。
^ Roubtsov, Vladimir (2003 年 5 月 9 日)。「Java バイトコード暗号化のクラッキング」。JavaWorld。2020年7 月 13 日閲覧。
^ deBoer, Tim; Karasiuk, Gary (2002 年 8 月 21 日)。「J2EE クラスローディングの解明」。IBM DeveloperWorks。2008年 1 月 26 日閲覧。
^ 「Depot - Apache Incubator」。2013年6月1日時点のオリジナルよりアーカイブ。
^ 「Jakarta Commons Logging によるクラスローダーの問題の分類」。
^ Bartlett, Neil; Hackbarth, Kai (2016-09-22). 「Java 9、OSGi、およびモジュール性の将来 (パート 1)」。InfoQ。

外部リンク

Chuck McManis、「Java クラスローダーの基礎」、1996 年
ブランドン E. テイラー、「Java クラスのロード: 基本事項 ( Wayback Machineで 2020-11-09 にアーカイブ) 」、2003 年
ケイ州ホーストマン（2022年4月15日）。コア Java。オラクルプレスJava。ISBN 0-13-787107-4。
Jeff Hanson、「Java でのクラス読み込みの制御 ( Wayback Machineで 2020-12-04 にアーカイブ) 」、2006-06-01
Andreas Schaefer、「クラスローダーの内部」、2003-11-12
Sheng Liang および Gilad Bracha、「Java 仮想マシンでの動的クラスローディング」、第 13 回 ACM オブジェクト指向プログラミング、システム、言語、およびアプリケーションカンファレンス (OOPSLA'98) の議事録、ACM SIGPLAN 通知、第 33 巻、第 10 号、ACM Press、1998 年、36 ～ 44 ページ、doi :10.1145/286936.286945
Jeremy Whitlock、「カスタムクラスローダーの実際の使用」、2005 年 5 月
Christoph G. Jung、「クラスローダーの再考、Hotdeploy」、Java Specialist Newsletter、2001-06-07
Don Schwarz、「ClassLoaders を使用したコンポーネント依存関係の管理」、2005-04-13

[7] ^これらのライブラリは 、rt.jar、core.jar、server.jarなどと呼ばれるJar ファイルに保存されます。

[1] Mcmanis, Chuck (1996 年 10 月 1 日). 「Java クラスローダーの基礎」. JavaWorld . 2020 年 7 月 13 日閲覧。

[FOOTNOTEHorstmann2022§10.1.1_The_Class-Loading_Process-2] Horstmann 2022、§10.1.1 クラスロードプロセス。

[FOOTNOTEHorstmann2022§8.2.5_Writing_Byte_Codes_to_Memory-3] Horstmann 2022、§8.2.5 バイトコードのメモリへの書き込み。

[Christudas-4] Christudas, Binildas (2005 年 1 月 26 日). 「Java クラスローディングの内部」onjava.com . 2018 年 5 月 10 日時点のオリジナルよりアーカイブ。

[TJT:UECL-5] 「拡張クラスのロードについて」。Java チュートリアル。docs.oracle.com。2020年7 月 13 日閲覧。

[6] Sosnoski, Dennis (2003 年 4 月 29 日)。「クラスとクラスローディング」。IBM DeveloperWorks。2008年 1 月 26 日閲覧。

[FOOTNOTEHorstmann202210.1.2_The_Class_Loader_Hierarchy-8] Horstmann 2022、10.1.2 クラスローダー階層。

[9] Roubtsov, Vladimir (2003 年 5 月 9 日)。「Java バイトコード暗号化のクラッキング」。JavaWorld。2020年7 月 13 日閲覧。

[10] Boer, Tim; Karasiuk, Gary (2002 年 8 月 21 日)。「J2EE クラスローディングの解明」。IBM DeveloperWorks。2008年 1 月 26 日閲覧。

[11] 「Depot - Apache Incubator」。2013年6月1日時点のオリジナルよりアーカイブ。

[12] 「Jakarta Commons Logging によるクラスローダーの問題の分類」。

[13] Bartlett, Neil; Hackbarth, Kai (2016-09-22). 「Java 9、OSGi、およびモジュール性の将来 (パート 1)」。InfoQ。