第5章 ロード、リンクおよび初期化

ブートストラップ・クラス・ローダーを使用して、Nで示される非配列クラスまたはインタフェースCをロードおよび作成するプロセスは、次のとおりです。

まず、Java Virtual Machineは、ブートストラップ・クラス・ローダーがNで示されるクラスまたはインタフェースの開始ローダーとしてすでに記録されているかどうかを判断します。 その場合、このクラスまたはインタフェースは Cであり、クラスのロードまたは作成は必要ありません。

それ以外の場合、Java Virtual Machineは引数Nをブートストラップ・クラス・ローダー上のメソッドの呼出しに渡します。 Cをロードするために、ブートストラップ・クラス・ローダーは、プラットフォームに依存した方法でCのパージされた表現を探し、Java Virtual Machineに、ブートストラップ・クラス・ローダーを使用してNで示されたクラスまたはインタフェースCを、§5.3.5のアルゴリズムを使用して、Cを作成するように依頼します。

通常、クラスまたはインタフェースは階層ファイル・システムのファイルを使用して表され、クラスまたはインタフェースの名前はファイルのパス名でエンコードされ、その特定に役立ちます。

Cのパージされた表現が見つからない場合、ブートストラップ・クラス・ローダーはClassNotFoundExceptionをスローします。 Cをロードおよび作成するプロセスは、ClassNotFoundExceptionの原因であるNoClassDefFoundErrorで失敗します。

Cのパージされた表現が見つかったが、パージされた表現から Cを導出できない場合は、同じ理由で Cをロードおよび作成するプロセスが失敗します。

それ以外の場合は、Cをロードおよび作成するプロセスが成功します。

ユーザー定義クラス・ローダーLを使用して、Nで示される非配列クラスまたはインタフェースCをロードおよび作成するプロセスは、次のとおりです。

まず、Java Virtual Machineは、LがすでにNで示されるクラスまたはインタフェースの開始ローダーとして記録されているかどうかを判断します。 その場合、このクラスまたはインタフェースは Cであり、クラスのロードまたは作成は必要ありません。

それ以外の場合、Java Virtual MachineはクラスClassLoaderのloadClassメソッドをLで起動し、クラスまたはインタフェースのNという名前を渡します。 Lは、ロードする次の2つの操作のいずれかを実行し、それによってクラスまたはインタフェースCを作成する必要があります。

実行される操作に関係なく、次のルールが適用されます。

LでのloadClassの起動に結果がある場合、次のようになります。

JDK 1.1以降、OracleのJava Virtual Machine実装は、クラス・ローダーで1引数のloadClassメソッドを呼び出して、クラスまたはインタフェースをロードするようにしました。 loadClassの引数は、ロードされるクラスまたはインタフェースの名前です。 loadClassメソッドには2つの引数のバージョンもあります。2番目の引数は、クラスまたはインタフェースをリンクするかどうかを示すbooleanです。 JDK 1.0.2では2引数バージョンのみが提供され、OracleのJava Virtual Machine実装はロードされたクラスまたはインタフェースをリンクするためにそれに依存していました。 JDK 1.1以降、OracleのJava Virtual Machine実装は、クラス・ローダーに依存せずに、クラスまたはインタフェースを直接リンクします。

次のステップを使用して、クラス・ローダーLに関連してNという名前の配列クラスCを作成します。 Lは、ブートストラップ・クラス・ローダーまたはユーザー定義クラス・ローダーのいずれかです。

まず、Java Virtual Machineは、LがNと同じコンポーネント・タイプの配列クラスの開始ローダーとしてすでに記録されているかどうかを判断します。 その場合、このクラスは Cであり、配列クラスを作成する必要はありません。

それ以外の場合は、次のステップを実行してCを作成します。

クラス・ローダーが存在する場合にタイプ・セーフ・リンケージを確保するには、特別な注意が必要です。 2つの異なるクラス・ローダーがNで示されるクラスまたはインタフェースのロードを開始すると、Nという名前が各ローダーで異なるクラスまたはインタフェースを示す場合があります。

クラスまたはインタフェースC = <N1の場合、L1>は、別のクラスまたはインタフェースD = <N2、L2>のフィールドまたはメソッドへのシンボリック参照を作成します。シンボリック参照には、フィールドの型を指定する記述子、またはメソッドの戻り型と引数型が含まれます。 フィールドまたはメソッド記述子(§4.3.2、§4.3.3)に記載されているクラス名またはインタフェース名Nは、L1によってロードされ、L2によってロードされるときに、同じクラスまたはインタフェースを示すことが不可欠です。

これを確実にするために、Java Virtual Machineでは、準備(§5.4.2)および解決(§5.4.3)中に、NL1 = NL2という形式のロード制約が課されます。 これらの制約を適用するために、Java Virtual Machineは特定の規定時間(§5.3.1、§5.3.2、§5.3.3および§5.3.5を参照)に、特定のローダーが特定のクラスの開始ローダーであることを記録します。 ローダーがクラスの開始ローダーであることを記録した後、Java Virtual Machineはすぐにロード制約に違反しているかどうかを確認する必要があります。 その場合、レコードは撤回され、Java Virtual MachineはLinkageErrorをスローし、記録の実行の原因となったロード操作は失敗します。

同様に、ロード制約を課した後(§5.4.2、§5.4.3.2、§5.4.3.3および§5.4.3.4を参照)、Java Virtual Machineは、ロード制約に違反しているかどうかをすぐに確認する必要があります。 その場合、新たに課せられたロード制約が撤回され、Java Virtual MachineはLinkageErrorをスローし、制約が課せられる原因となった操作(場合によっては解決または準備)は失敗します。

ここで説明する状況は、Java Virtual Machineがロード制約に違反しているかどうかをチェックする唯一の時間です。 ロード制約は、次の4つの条件がすべて保持されている場合にのみ違反します。

クラス・ローダーと型安全性に関する完全な説明は、この仕様の範囲外です。 より包括的な説明については、Sheng LiangとGilad BrachaによるDynamic Class Loading in the Java Virtual Machineを参照してください(Proceedings of the 1998 ACM SIGPLAN Conference on Object-Oriented Programming Systems、 Languages and Applications)。

クラス・ローダーでは、ローダーによって提供されるバイナリ表現(§5.3.1、§5.3.2)からクラスまたはインタフェースを導出および作成するために、Java Virtual Machineの連携が必要です。 次のステップは、Nで示されるクラスまたはインタフェースCを、クラス・ローダーLによってリクエストされた場合に、classファイル形式のパージされた表現から導出するために使用されます。

ステップ1から4で例外がスローされない場合、クラスまたはインタフェースCの導出は成功します。 Java Virtual Machineは、定義ローダーとしてLを持つようにCをマークし、LがCの開始ローダー(§5.3.4)であることを記録し、メソッド領域にCを作成します(§2.5.4)。

導出が成功すると、Cのロードおよび作成のプロセスは、Cのロードに関与するすべてのクラス・ローダーが(直接または間接的に)結果としてCを返すまで完了しません。 ユーザー定義クラス・ローダーの動作によっては、Cのロードおよび作成のプロセスがまだ失敗する場合があります(§5.3.2)。

ステップ1から4で例外がスローされた場合、クラスまたはインタフェースCの導出は、その例外で失敗します。

クラスまたはインタフェースを導出するリクエストは、複数のスレッドで実行されるクラス・ローダー・コードによって同時に行うことができますが、導出プロセスは順次行われます。 Java Virtual Machine実装では、特定のクラス・ローダーによる特定の名前のクラスまたはインタフェースを導出するリクエストが一度に1つのみ処理され、他のすべてのリクエストは最初のリクエストが完了するまで待機します。

導出プロセスで指定したとおり、最初のリクエストが成功した場合、後続のリクエストは許可されません。 ClassLoader APIは、導出リクエストを同期し、成功した結果をキャッシュするメカニズムを提供して、冗長な導出リクエストが発生しないようにします。

Java Virtual Machineは、モジュールへのクラスおよびインタフェースの編成をサポートしています。 モジュール M内のクラスまたはインタフェース Cのメンバーシップは、M (§5.4.4)以外のモジュールのクラスおよびインタフェースからの Cへのアクセスを制御するために使用されます。

モジュール・メンバーシップは、ランタイム・パッケージ(§5.3)で定義されています。 プログラムは、各モジュール内のパッケージの名前、および名前付きパッケージのクラスとインタフェースを作成するクラス・ローダーを決定します。その後、クラスModuleLayerのdefineModulesメソッドの呼出しに対するパッケージおよびクラス・ローダーを指定します。 defineModulesを起動すると、Java Virtual Machineは、クラス・ローダーのランタイム・パッケージに関連付けられた新しいランタイム・モジュールを作成します。

すべてのランタイム・モジュールは、エクスポートするランタイム・パッケージを示します。これは、それらのランタイム・パッケージ内のpublicクラスおよびインタフェースへのアクセスに影響します。 すべてのランタイム・モジュールは、読取りする他のランタイム・モジュールも示します。これは、それらのランタイム・モジュール内のpublic型およびインタフェースへの独自のコードによるアクセスに影響します。

クラスがランタイム・モジュール内にあるということは、クラスのランタイム・パッケージがそのランタイム・モジュールに関連付けられている(または、クラスが実際に作成されている場合は関連付けられている)場合です。

クラス・ローダーによって作成されるクラスは、1つのランタイム・パッケージ内に存在するため、1つのランタイム・モジュールのみに存在します。これは、Java Virtual Machineでは、複数のランタイム・モジュールに関連付けられている(つまり、複数のランタイム・モジュールにまたがって分割される)ランタイム・パッケージがサポートされていないためです。

ランタイム・モジュールは、defineModulesのセマンティクスによって、1つのクラス・ローダーに暗黙的にバインドされます。 一方、Java Virtual Machineでは、クラス・ローダーのすべてのランタイム・パッケージを同じランタイム・モジュールに関連付ける必要がないため、クラス・ローダーは複数のランタイム・モジュールにクラスを作成できます。

つまり、クラス・ローダーとランタイム・モジュール間の関係は1:1である必要はありません。 ロードする特定のモジュール・セットについて、各モジュール内のパッケージの名前がそのモジュール内でのみ見つかることをプログラムが判断できる場合、プログラムはdefineModulesの呼出しに対して1つのクラス・ローダーのみを指定できます。 このクラス・ローダーは、複数のランタイム・モジュールにまたがるクラスを作成します。

defineModulesによって作成されるすべてのランタイム・モジュールは、レイヤーの一部です。 レイヤーは、一連のランタイム・モジュールにクラスを作成するために共同で機能する一連のクラス・ローダーを表します。 レイヤーには、Java Virtual Machineによって提供されるブート・レイヤーとユーザー定義レイヤーの2種類があります。 ブート・レイヤーは、実装に依存した方法でJava Virtual Machineの起動時に作成されます。 標準ランタイム・モジュールjava.baseを、ブートストラップ・クラス・ローダーで定義された標準ランタイム・パッケージ(java.langなど)に関連付けます。 ユーザー定義レイヤーは、java.baseおよびその他の標準ランタイム・モジュールに依存するランタイム・モジュールのセットを構築するために、プログラムによって作成されます。

ランタイム・モジュールは、defineModulesのセマンティクスによって暗黙的に1つのレイヤーの一部になります。 ただし、クラス・ローダーでは、異なるレイヤーのランタイム・モジュールにクラスを作成できます。これは、同じクラス・ローダーをdefineModulesの複数の呼出しに指定できるためです。 アクセス制御は、クラスを作成したクラス・ローダーまたはクラス・ローダーが処理するレイヤーではなく、クラスのランタイム・モジュールによって制御されます。

レイヤーに指定されたクラス・ローダーのセットと、レイヤーの一部であるランタイム・モジュールのセットは、レイヤーの作成後に不変になります。 ただし、ModuleLayerクラスでは、プログラムがユーザー定義レイヤー内のランタイム・モジュール間の関係を動的に制御できます。

ユーザー定義レイヤーに複数のクラス・ローダーが含まれている場合、クラス・ローダー間の委任は、レイヤーを作成したプログラムの責任となります。 Java Virtual Machineでは、レイヤーのランタイム・モジュールが相互に読み取る方法に従って、レイヤーのクラス・ローダーが相互に委任されているかどうかはチェックされません。 さらに、レイヤーのランタイム・モジュールがModuleLayerクラスを介して変更され、追加のランタイム・モジュールが読み取られる場合、Java Virtual Machineは、レイヤーのクラス・ローダーが、対応する方法で委任するためにバンド外メカニズムによって変更されていることをチェックしません。

クラス・ローダーとレイヤーには類似点と相違点があります。 一方、レイヤーはクラス・ローダーに似ており、それぞれが、以前にモジュールまたはクラスを作成した1つ以上の親レイヤーまたはクラス・ローダーにそれぞれ委任できます。 つまり、レイヤーに指定されるモジュールのセットは、レイヤーに指定されていないモジュールに依存し、かわりに1つ以上の親レイヤーに以前に指定されているモジュールに依存する場合があります。 一方、レイヤーは、新しいモジュールの作成に1回のみ使用できますが、クラス・ローダーは、defineClassメソッドの複数の呼出しを介して、いつでも新しいクラスまたはインタフェースを作成するために使用できます。

クラス・ローダーは、クラス・ローダーが処理するレイヤーによってランタイム・モジュールに関連付けられていなかったランタイム・パッケージ内のクラスまたはインタフェースを定義できます。 これは、ランタイム・パッケージがdefineModulesに指定されていない名前付きパッケージを体現する場合、またはクラスまたはインタフェースが単純なバイナリ名(§4.2.1)を持ち、無名パッケージ(JLS§7.4.2)を体現するランタイム・パッケージのメンバーである場合に発生する可能性があります。 いずれの場合も、クラスまたはインタフェースは、クラス・ローダーに暗黙的にバインドされる特別なランタイム・モジュールのメンバーとして扱われます。 この特別なランタイム・モジュールは、クラス・ローダーの名前なしモジュールと呼ばれます。 クラスまたはインタフェースのランタイム・パッケージは、クラス・ローダーの名前のないモジュールに関連付けられます。 名前のないモジュールには、他のランタイム・モジュールとの相互運用性を最大限にするために設計された特別なルールが次のようにあります。

Verification (§4.10)は、クラスまたはインタフェースのバイナリ表現が構造的に正しいことを保証します(§4.9)。 検証により、追加のクラスおよびインタフェースがロードされる場合がありますが(§5.3)、検証または準備する必要はありません。

クラスまたはインタフェースのバイナリ表現が§4.9にリストされている静的制約または構造的制約を満たさない場合、クラスまたはインタフェースが検証される原因となったプログラム内のポイントでVerifyErrorがスローされる必要があります。

LinkageError (またはサブクラス)のインスタンスであるエラーがスローされたためにJava Virtual Machineがクラスまたはインタフェースを検証しようとして失敗した場合、後続のクラスまたはインタフェースの検証試行は、最初の検証試行の結果としてスローされたものと同じエラーで常に失敗します。

準備では、クラスまたはインタフェースの静的フィールドを作成し、それらのフィールドをデフォルト値に初期化します(§2.3、§2.4)。 この場合、Java Virtual Machineコードの実行は必要ありません。静的フィールドの明示的な初期化子は、準備ではなく初期化(§5.5)の一部として実行されます。

クラスまたはインタフェースCの準備中に、Java Virtual Machineではロード制約も課されます(§5.3.4)。

準備は作成後いつでも行うことができますが、初期化の前に完了する必要があります。

多くのJava Virtual Machine命令- anewarray、checkcast、getfield、getstatic、instanceof、invokedynamic、invokeinterface、invokespecial、invokestatic、invokevirtual、ldc、ldc_w、ldc2_w、multianewarray、new、putfield、putstatic - 実行時定数プール内のシンボリック参照に依存します。 これらの命令のいずれかを実行するには、シンボリック参照の解決策が必要です。

解決法は、実行時定数プール内のシンボリック参照から1つ以上の具体的な値を動的に決定するプロセスです。 最初は、実行時定数プール内のすべてのシンボリック参照が解決されません。

(i)クラスまたはインタフェース、(ii)フィールド、(iii)メソッド、(iv)メソッド・タイプ、(v)メソッド・ハンドル、(vi)動的に計算された定数に対する未解決のシンボリック参照の解決は、§5.4.3.1から§5.4.3.5までのルールに従って進みます。 これらのセクションの最初の3つのセクションでは、シンボリック参照が表示される実行時定数プールのクラスまたはインタフェースには Dというラベルが付けられています。 次に、

解決時の初期試行で発生したエラーは、後続の試行で再度スローされるため、1つのモジュール内のクラスで、実行時定数プール内のシンボリック参照の解決を介して、エクスポートされないpublic型にアクセスしようとします。別のモジュールでは、Java SE Platform APIを使用してクラスの最初の試行後にpublic型のパッケージを動的にエクスポートする場合でも、、アクセスできない型(§5.4.4)を示す同じエラーが常に返されます。

動的に計算されたコール・サイトへの未解決のシンボリック参照の解決は、§5.4.3.6に記載されている規則に従って進められます。 次に、

前述の手順の中には、シンボリック参照を解決する際に追加のリンク・チェックが必要なものがあります。 たとえば、getfield命令が動作するフィールドへのシンボリック参照を正常に解決するためには、§5.4.3.2に示されているフィールド解決ステップを完了するだけでなく、フィールドがstaticでないこともチェックする必要があります。 staticフィールドの場合は、リンク例外をスローする必要があります。

特定のJava Virtual Machine命令の実行に固有のチェックによって生成された例外のリンクは、その命令の説明に示されており、この解決に関する一般的な説明では説明していません。 このような例外は、解決ではなくJava Virtual Machine命令の実行の一部として記述されていますが、解決の失敗と引き続き適切にみなされます。

アクセス制御は、クラス、インタフェース、フィールドまたはメソッドへの参照が許可されるように、解決(§5.4.3)中に適用されます。 アクセス制御は、指定されたクラス、インタフェース、フィールドまたはメソッドが参照クラスまたはインタフェースに対してアクセス可能である場合に成功します。

クラスまたはインタフェース Cは、次のいずれかに該当する場合にのみ、クラスまたはインタフェース Dからアクセスできます。

CにDからアクセスできない場合、アクセス制御はIllegalAccessErrorをスローします。 それ以外の場合、アクセス制御は成功します。

フィールドまたはメソッドRは、次のいずれかに該当する場合にのみ、クラスまたはインタフェースDからアクセスできます。

DからRにアクセスできない場合、アクセス制御はIllegalAccessErrorをスローします。 それ以外の場合、アクセス制御は成功します。

ネストは、privateメンバーへの相互アクセスを許可するクラスおよびインタフェースのセットです。 クラスまたはインタフェースの1つがネスト・ホストです。 NestMembers属性(§4.7.29)を使用して、ネストに属するクラスおよびインタフェースを列挙します。 それぞれが、NestHost属性(§4.7.28)を使用してネスト・ホストとして指定されます。 NestHost属性を持たないクラスまたはインタフェースは、それ自体がホストするネストに属します。NestMembers属性もない場合、このネストは、クラスまたはインタフェース自体のみで構成されるシングルトンです。

Java Virtual Machineは、クラスまたはインタフェースがロードされるときではなく、特定のクラスまたはインタフェースが属するネスト(つまり、クラスまたはインタフェースによって指定されたネスト・ホスト)をアクセス制御の一部として決定します。 Java SE Platform APIの特定のメソッドは、アクセス制御の前に、特定のクラスまたはインタフェースが属するネストを決定できます。その場合、Java Virtual Machineはアクセス制御中に事前に決定したことを尊重します。

クラスまたはインタフェースCがクラスまたはインタフェースDと同じネストに属しているかどうかを判断するために、ネストメイト・テストが適用されます。 Cと Dは、ネストメートテストが成功した場合にのみ、同じネストに属します。 nestmateテストは以下の通りです。

クラスまたはインタフェースMのネスト・ホストは、次のように決定されます。

次のすべてに該当する場合、インスタンス・メソッドmCは別のインスタンス・メソッドmAをオーバーライドできます。

public class A           {        void m() {} }
public class B extends A { public void m() {} }
public class C extends B {        void m() {} }

public class D extends P.C { void m() {} }

invokeinterfaceまたはinvokevirtual命令の実行中、メソッドは、(i)スタック上のオブジェクトの実行時型、および(ii)命令によって以前に解決されたメソッドに関して選択されます。 クラスまたはインタフェースCおよびメソッドmRに関してメソッドを選択するルールは、次のとおりです。

通常、Cはクラスですが、準備中にこれらのルールが適用される場合にはインタフェースになることがあります(§5.4.2)。