sealedクラス

このドキュメントでは、Java SE 15のプレビュー機能であるsealedクラスおよびインタフェースをサポートするためのJava仮想マシン仕様に対する変更について説明します。sealedクラスまたはインタフェースは、許可されたサブクラスまたはサブインタフェースの列挙セットに対する拡張と実装を制限します。この機能の概要は、JEP 360を参照してください。

セクション4.7では、新しいPermittedSubclasses属性を指定します。

セクション5.3.5では、PermittedSubclasses属性を適用するためにクラスの導出時に実行されるチェックを指定します。

新しいクラスの作成チェックが参照実装の既存の動作とどのように相互作用するかをより正確に指定するために、5.3に対するいくつかの改訂も含まれています。

変更は、JVM仕様の既存のセクションに関して説明します。新しいテキストはこのように示され、削除されたテキストはこのように示されます。必要に応じて、説明と考察が端の方にグレーのボックスで囲まれて記載されています。

第4章: classファイル形式

4.7 属性

属性は、classファイル形式のClassFile、field_info、method_infoおよびCode_attribute構造体で使用されます(4.1、4.5、4.6、4.7.3)。

すべての属性が次の一般的な形式を持ちます。

attribute_info {
    u2 attribute_name_index;
    u4 attribute_length;
    u1 info[attribute_length];
}

すべての属性について、attribute_name_index項目は、クラスの定数プールに対して有効な符号なし16ビット索引である必要があります。attribute_name_indexでのconstant_poolエントリは、属性の名前を表すCONSTANT_Utf8_info構造体(4.4.7)である必要があります。attribute_length項目の値は、後続の情報の長さをバイト単位で示します。この長さには、attribute_name_indexおよびattribute_length項目を含む先頭の6バイトは含まれません。

2829の属性がこの仕様によって事前に定義されています。これらは、ナビゲートしやすいように3回に分けてリストされています。

• 表4.7-Aは、この章の属性のセクション番号で順序付けられています。各属性は、それが定義されたclassファイル形式の最初のバージョンで示されています。もう1つ示されているのは、classファイル形式のそのバージョンを導入したJava SEプラットフォームのバージョンです(4.1)。

• 表4.7-Bは、各属性が定義されたclassファイル形式の最初のバージョンで順序付けられています。

• 表4.7-Cは、各属性の出現が定義されているclassファイル内の場所で順序付けられています。

この仕様でのこれらの使用状況、つまり、これらが出現するclassファイル構造体のattributes表において、これらの事前定義済の属性の名前が予約されています。

attributes表内における事前定義済の属性の存在に関する条件は、属性を説明するセクションで明示的に規定されています。条件が規定されていない場合、属性はattributes表内に任意の回数出現する場合があります。

事前定義済の属性は、その目的に応じて3つのグループに分類されます。

1. Java仮想マシンによるclassファイルの正しい解釈には、6つ7つの属性が不可欠です。

   • ConstantValue
   • Code
   • StackMapTable
   • BootstrapMethods
   • NestHost
   • NestMembers
   • PermittedSubclasses

   バージョン番号がvであるclassファイル内では、Java仮想マシンの実装がclassファイル形式のバージョンvをサポートしており、属性がclassファイル形式のバージョンv以前で最初に定義されたもので、その属性が出現先として定義されている場所に出現している場合、これらの各属性はJava仮想マシンの実装によって識別され、適切に読み取られます。

2. 9つの属性は、Java仮想マシンによるclassファイルの正しい解釈に不可欠ではありませんが、Java SEプラットフォームのクラス・ライブラリによるclassファイルの正しい解釈に不可欠であるか、ツールの役に立ちます(この場合、属性を規定するセクションは「オプション」として記載されています)。

   • Exceptions
   • InnerClasses
   • EnclosingMethod
   • Synthetic
   • Signature
   • SourceFile
   • LineNumberTable
   • LocalVariableTable
   • LocalVariableTypeTable

   バージョン番号がvであるclassファイル内では、Java仮想マシンの実装がclassファイル形式のバージョンvをサポートしており、属性がclassファイル形式のバージョンv以前で最初に定義されたもので、その属性が出現先として定義されている場所に出現している場合、これらの各属性はJava仮想マシンの実装によって識別され、適切に読み取られます。

3. 13の属性は、Java仮想マシンによるclassファイルの正しい解釈に不可欠ではありませんが、Java SEプラットフォームのクラス・ライブラリによって公開されるclassファイルに関するメタデータを含むか、ツールによって使用可能になります(この場合、属性を規定するセクションは「オプション」として記載されています)。

   • SourceDebugExtension
   • Deprecated
   • RuntimeVisibleAnnotations
   • RuntimeInvisibleAnnotations
   • RuntimeVisibleParameterAnnotations
   • RuntimeInvisibleParameterAnnotations
   • RuntimeVisibleTypeAnnotations
   • RuntimeInvisibleTypeAnnotations
   • AnnotationDefault
   • MethodParameters
   • Module
   • ModulePackages
   • ModuleMainClass

   Java仮想マシンの実装では、これらの属性に含まれる情報が使用される場合がありますが、そうでない場合、これらの属性は内部で無視する必要があります。

4.7.30 PermittedSubclasses属性

PermittedSubclasses_attribute {
    u2 attribute_name_index;
    u4 attribute_length;
    u2 number_of_classes;
    u2 classes[number_of_classes];
}

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

5.3 作成およびロード

名前Nによって示されるクラスまたはインタフェースCの作成は、クラスまたはインタフェース(4)のバイナリ表現の特定、およびJava仮想マシンのメソッド領域(2.5.4)内のCの実装固有の内部表現の仮想マシンのメソッド領域内の構造体(2.5.4)の導出で構成されています。

クラスまたはインタフェースの作成は、実行時定数プールを介してCを参照する別のクラスまたはインタフェースDによってトリガーされます。また、クラスまたはインタフェースの作成は、リフレクションなどの特定のJava SEプラットフォームのクラス・ライブラリ(2.12)内のメソッドを呼び出すDによってもトリガーされる場合があります。

クラスまたはインタフェースの作成が実行時定数プールからのCへの参照によってトリガーされる場合、このセクションで説明するプロセスに従います。Java SEプラットフォームのクラス・ライブラリ内のメソッドによってトリガーされるクラスまたはインタフェースの作成も、同様のプロセスに従います。その詳細は、このメソッドによって規定されます。

Cが配列クラスではない場合、C (4)のバイナリ表現をロードすることによって作成クラス・ローダーを使用してロードすることによって作成されます。配列クラスには外部バイナリ表現はありません。配列クラスは、クラス・ローダーによってではなく、Java仮想マシンによって作成されます。

クラス・ローダーには、Java仮想マシンによって提供されるブートストラップ・クラス・ローダーとユーザー定義のクラス・ローダーの2種類があります。ユーザー定義のクラス・ローダーはすべて、abstractクラスClassLoaderのサブクラスのインスタンスです。アプリケーションは、Java仮想マシンがクラスを動的にロードすることによって作成する方法を拡張するためにユーザー定義のクラス・ローダーを採用します。ユーザー定義のクラス・ローダーは、ユーザー定義のソースが作成元であるクラスを作成するために使用できます。たとえば、クラスは、ネットワーク全体にわたってダウンロードしたり、その場で生成したり、暗号化されたファイルから抽出できます。

ユーザー定義のクラス・ローダーは、ユーザー定義のソースが作成元であるクラスを作成するために使用できます。たとえば、クラスは、ネットワーク全体にわたってダウンロードしたり、その場で生成したり、暗号化されたファイルから抽出できます。

クラス・ローダーLは、Cを直接定義定義するか、別のクラス・ローダーに委譲することにより、作成ロードできます。LがCを直接作成定義する場合、Oracleでは、LがCを定義する、言い換えると、LはCを定義するローダーである、と言います。

1つのクラス・ローダーが別のクラス・ローダーに委譲する場合、ロードを開始するローダーは必ずしも、ロードを完了してクラスを定義するローダーと同じものである必要はありません。LがCを直接定義することによるか委譲によって作成ロードする場合、Oracleでは、LがCのロードを開始する、言い換えると、LはCを開始するローダーである、と言います。

実行時方法には、クラスまたはインタフェースが、名前のみによってではなく、ペア(バイナリ名(4.2.1)と定義する側のクラス・ローダー)によって決定されます。このような各クラスまたはインタフェースは、単一の実行時パッケージに属します。クラスまたはインタフェースの実行時パッケージは、パッケージ名、およびクラスまたはインタフェースを定義するクラス・ローダーによって決定されます。

Java仮想マシンは、Nによって示されるクラスまたはインタフェースCを作成するために3つの手順のうち1つを使用します。

• Nが配列以外のクラスまたはインタフェースを示す場合、Cをロードして作成するために次の2つのメソッドの1つを使用します。

  • Dがブートストラップ・クラス・ローダーによって定義された場合、ブートストラップ・クラス・ローダーがCのロードを開始します(5.3.1)。

  • Dがユーザー定義のクラス・ローダーによって定義された場合、これと同じユーザー定義のクラス・ローダーがCのロードを開始します(5.3.2)。

• それ以外の場合、Nが配列クラスを示します。配列クラスは、クラス・ローダーによってではなく、Java仮想マシンによって直接作成されます(5.3.3)。ただし、Dを定義するクラス・ローダーは、配列クラスCの作成プロセスで使用されます。

クラスのロード中にJava仮想マシンが作成を作成しようとしているときにエラーが発生した場合、ロード中のクラスまたはインタフェースを(直接または間接的に)使用するプログラム内のある時点でLinkageErrorのサブクラスのインスタンスがスローされる必要があります。

検証(5.4.1)または解決(5.4.3)中に(ただし、初期化(5.5)中ではなく) Java仮想マシンがクラスCを常にロードしようとしており、Cのロードを開始するために使用されるクラス・ローダーがClassNotFoundExceptionのインスタンスをスローする場合、Java仮想マシンは、原因がClassNotFoundExceptionのインスタンスであるNoClassDefFoundErrorのインスタンスをスローする必要があります。

(ここでの微妙な違いは、スーパークラスをロードするための回帰クラスが解決の一部(5.3.5、ステップ3)で実行される点です。したがって、スーパークラスのロードに失敗したクラス・ローダーの結果として生成されるClassNotFoundExceptionは、NoClassDefFoundErrorでラップする必要があります。)

正常に動作するクラス・ローダーは、3つの特性を有している必要があります。

• 同じ名前が与えられた場合、正常に動作するクラス・ローダーは常に同じClassオブジェクトを返す必要があります。

• クラス・ローダーL₁がCのロードを別のクラス・ローダーL₂に委譲する場合、Cの直接スーパークラスまたは直接スーパーインタフェースとして、また、C内のフィールドの型として、またはC内のメソッドまたはコンストラクタの仮パラメータの型として、またはC内のメソッドの戻り型として生成される任意の型Tについて、L₁およびL₂は同じClassオブジェクトを返す必要があります。

• ユーザー定義のクラス・ローダーがクラスおよびインタフェースのバイナリ表現をプリフェッチするか、関連するクラスのグループをまとめてロードする場合、プリフェッチまたはグループでのロードがなかったらロード・エラーが起きていた可能性があるプログラム内のポイントでのみロード・エラーを反映する必要があります。

Oracleではときどき、<N, L_d>という表記を使用してクラスまたはインタフェースを表すことがあります。この場合、Nはクラスまたはインタフェースの名前を示し、L_dはクラスまたはインタフェースを定義するローダーを示します。

また、N^L_iという表記を使用してクラスまたはインタフェースを表すこともあります。この場合、Nはクラスまたはインタフェースの名前を示し、L_iはクラスまたはインタフェースを開始するローダーを示します。

5.3.1 ブートストラップ・クラス・ローダーを使用したロード作成

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

最初に、Java仮想マシンが、Nによって示されるクラスまたはインタフェースを開始するローダーとしてブートストラップ・クラス・ローダーがすでに記録されているかどうかを確認します。記録されている場合、このクラスまたはインタフェースはCであり、クラスの作成は必要ありません。

記録されていない場合、Java仮想マシンは、引数Nをブートストラップ・クラス・ローダーのメソッドの呼出しに渡し、Cを検索ロードします。これには、プラットフォームに依存する方法で意図するCの表現を検索する操作、および5.3.5で見つかったアルゴリズムを使用してこの表現からCを導出する操作が含まれます。通常、クラスまたはインタフェースは階層ファイル・システム内のファイルを使用して表現され、クラスまたはインタフェースの名前はこのファイルのパス名内にエンコードされます。

5.3.2 ユーザー定義のクラス・ローダーを使用したロード作成

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

最初に、Java仮想マシンが、Nによって示されるクラスまたはインタフェースを開始するローダーとしてLがすでに記録されているかどうかを確認します。記録されている場合、このクラスまたはインタフェースはCであり、クラスの作成は必要ありません。

それ以外の場合、Java仮想マシンはLに対してloadClass(N)を呼び出します。この呼出しによって返される値は、作成されたクラスまたはインタフェースCです。この場合、Java仮想マシンは、このLがCを開始するローダーであることを記録します(5.3.4)。このセクションの残りの部分では、このプロセスのプロセスについてさらに詳しく説明します。

ロード対象のクラスまたはインタフェースCの名前Nを使用してクラス・ローダーLのloadClassメソッドが呼び出される場合、Lは、Cをロードするために次の2つの操作の1つを実行する必要があります。

1. クラス・ローダーLは、Cを表すバイトの配列をClassFile構造体(4.1)のバイトとして作成できます。この場合、このクラス・ローダーは、クラスClassLoaderのメソッドdefineClassを呼び出す必要があります。defineClassを呼び出すと、Java仮想マシンが、5.3.5で見つかったアルゴリズムを使用したバイトの配列のLを使用して、Nによって示されるクラスまたはインタフェースを導出します。

   意図する表現からのCの導出が失敗した場合、5.3.5に記載されているいずれかのエラーがloadClassによってスローされる可能性があります。同じ理由でCの作成が失敗します。

   loadClassによって生成されたクラスまたはインタフェースが名前Nを持つが、defineClassによって導出されたクラスまたはインタフェースとは異なる場合、作成は失敗し、Java仮想マシンは、LinkageErrorのインスタンスまたはLinkageErrorのサブクラスをスローします。

2. クラス・ローダーLは、Cのロードを他のクラス・ローダーLに委譲できます。これを実現するには、引数NをLに対するメソッド(通常はloadClassメソッド)の呼出しに直接または間接的に渡します。この呼出しの結果はCです。

(1)または(2)の場合、クラス・ローダーLがなんらかの理由により、Nによって示されるクラスまたはインタフェースをロードできない場合、ClassNotFoundExceptionのインスタンスをスローする必要があります。この場合、Cの作成は失敗し、ブートストラップ・クラス・ローダーによって生成されたClassNotFoundExceptionが原因であるNoClassDefFoundErrorが発生します。

loadClass呼出しの結果がnullであるか、N以外の名前を持つロードされたクラスまたはインタフェースである場合、作成は失敗し、NoClassDefFoundErrorがスローされます。

JDK 1.1以降、OracleのJava仮想マシンの実装により、クラス・ローダーのloadClassメソッドが呼び出され、これにより、クラスまたはインタフェースがロードされます。loadClassの引数は、ロード対象のクラスまたはインタフェースの名前です。loadClassメソッドには2つの引数バージョンもあります。この場合、2番目の引数は、クラスまたはインタフェースをリンクするかどうかを示すbooleanです。JDK 1.0.2ではこの2つの引数バージョンのみが提供されていたため、OracleのJava仮想マシンの実装は、ロードされたクラスまたはインタフェースをリンクするためにこれを使用していました。JDK 1.1以降、OracleのJava仮想マシンの実装では、クラス・ローダーを使用することなく、クラスまたはインタフェースを直接リンクしています。

5.3.5 classファイル表現からのクラスの導出

次のステップを使用して、classファイル形式の意図する表現からのローダーLを使用してNによって示される非配列クラスまたはインタフェースCのClassオブジェクトを作成します。

1. 最初に、Java仮想マシンが、LがNによって示されるクラスまたはインタフェースを開始するローダーであることをすでに記録しているかどうかを確認します。記録している場合、この作成試行は無効であり、ロードにより、LinkageErrorがスローされます。クラス・ローダーLのNという名前のクラスまたはインタフェースの導出試行が無効であるかどうかを確認します。無効である場合、導出によってLinkageErrorがスローされます。

   次のいずれかが当てはまる場合、クラス・ローダーLのNという名前のクラスまたはインタフェースを導出しようとする試みは無効です。

   • Nという名前のクラスまたはインタフェースを開始するローダーとしてLがすでに記録されている。

   • Lがブートストラップ・クラス・ローダー(5.3)ではなく、Nが予約名java/lang/Objectである。

   2番目の事例を4.1での制約と組み合せることにより、クラス階層のルートが1つのみ存在するよう徹底します。これにより、名前java/lang/Objectを使用してそれを確実に参照できるようになります。

   Java SE APIでは、java.*を含む特定のパッケージ内のクラスをロードしようとする不正な試みを阻止するために追加のセキュリティ制約が適用されています。

   実際に、このセキュリティ制約により、Objectルールをテストできなくなります。具体的には、JVMがこのチェックを実行する前にSecurityExceptionが発生します。しかし、内部的な一貫性のために、明言することが重要です。

2. それ以外の場合、Java仮想マシンは、意図する表現を解析しようとします。ただし、意図する表現は実際にはCの有効な表現ではない場合があります。

   ロード導出のこのフェーズでは、次のエラーを検出する必要があります。

   • 意図する表現がClassFile構造体(4.1、4.8)ではない場合、ロードによってClassFormatErrorのインスタンスがスローされます。

     バージョン番号がサポートされているかどうかを確認する前にclassファイルを解析しようとしても意味がありません。バージョンのチェックを最初に行う必要があります。

   • それ以外の場合、意図する表現がサポートされているメジャー・バージョンまたはマイナー・バージョンではない(4.1)5番目～8番目のバイトでメジャー・バージョンまたはマイナー・バージョン番号を提供するが(4.1)、バージョン番号がこのJava仮想マシンの実装ではサポートされていない場合、ロード導出によってUnsupportedClassVersionErrorのインスタンスがスローされます。

     ClassFormatErrorのサブクラスであるUnsupportedClassVersionErrorは、サポートされていないバージョンのclassファイル形式を表現が使用するクラスをロードする試みが原因であるClassFormatErrorを簡単に特定できるようにするために導入されました。JDK 1.1以前では、クラスがシステム・クラス・ローダーまたはユーザー定義のクラス・ローダーのどちらによってロードされたかに応じて、サポートされていないバージョンの場合にNoClassDefFoundErrorまたはClassFormatErrorのインスタンスがスローされていました。

   • それ以外の場合、意図する表現がClassFile構造体(4.1、4.8)ではない場合、導出によってClassFormatErrorのインスタンスがスローされます。

   • それ以外の場合、意図する表現がNという名前のクラスまたはインタフェースを実際に表していない場合、ロード導出により、NoClassDefFoundErrorのインスタンスまたはそのサブクラスのインスタンスがスローされます。

     このようになるのは、意図する表現に、N以外の名前を指定するthis_class項目、またはACC_MODULEフラグが設定されたaccess_flags項目のいずれかが含まれる場合です。

3. Cに直接スーパークラスがある場合、Cから直接スーパークラスへのシンボリック参照は5.4.3.1のアルゴリズムを使用して解決されます。Cがインタフェースである場合、Objectを直接スーパークラスとして持つ必要があります。ただし、これはすでにロードされている必要があります。直接スーパークラスを持たないのはObjectのみです。

   5.2に従って、任意の初期クラスまたはインタフェースが最初に作成されます。初期クラスまたはインタフェースがインタフェースである場合、これを導出すると、(まだロードされていない) Objectの作成がここで再帰的に要求されます。

   ロード導出のこのフェーズの結果として、クラスまたはインタフェースの解決が原因でスローできる任意の例外をスローできます。また、ロード導出のこのフェーズでは、次のエラーを検出する必要があります。

   • Cの直接スーパークラスとして名前が付けられたクラスまたはインタフェースが実際にインタフェースである場合、ロードによってIncompatibleClassChangeErrorがスローされます。

   • それ以外の場合、Cの任意のスーパークラスがC自体である場合直接スーパークラスを解決しようとした結果、現在のスレッドがローダーLを使用してNという名前のクラスを再帰的に導出しようとする場合、ロード導出によってClassCircularityErrorがスローされます。

     スーパークラスを実際に最初に作成せずに、スーパークラスが「C自体」であることをどうすれば判定できますか。もちろん、このチェックを再帰的に適用せずにスーパークラスを作成することはできません。この依存関係ループは、Nという名前のクラスを導出する2回目の試行が行われたことが検出されたときに壊れます。

   • それ以外の場合、Cの直接スーパークラスとして名前が付けられたクラスまたはインタフェースがインタフェースまたはfinalクラスである場合、導出によってVerifyErrorがスローされます。

     このチェックは長い間、検証の一部として指定されています(4.10、4.10.1)。ただし、JDK 14とOpenJ9は両方とも、それをクラス導出の一部として実行します。

     このステージでのVerifyErrorは場違いですが、これは実際にスローされる例外です。JDK-8243582を参照してください。

   • それ以外の場合、Cの直接スーパークラスとして名前が付けられたクラスがPermittedSubclasses属性(4.7.30)を持ち、次のいずれかが当てはまる場合、導出は失敗してIncompatibleClassChangeErrorがスローされます。

     • このスーパークラスが、Cとは異なる実行時モジュールに属している。

     • CにはACC_PUBLICフラグ(4.1)が設定されておらず、このスーパークラスが、Cとは異なる実行時パッケージに属している。

     • スーパークラスのPermittedSubclasses属性のclasses表内のエントリが、名前Nを持つクラスまたはインタフェースを参照していない。

   これらの制約により、スーパークラスのPermittedSubclasses内のエントリがCに解決されるよう保証されます。(Oracleでは、参照を実際にCに解決することはありません。なぜなら、そのようにすると、Cの導出がまだ完了していないため、循環性が要求されるためです。)

   Java言語には追加要件があるため、名前が付いていないモジュールにクラスが属する場合、これらのクラスはともに同じパッケージに属する必要があります。これにより、プログラマがこの機能を適切に使用することが促進されますが(プログラマは様々なメンテナンス・ドメインにわたってsealed階層を広げようとすべきではありません)、これは、JVMが適用する必要があるような種類の基本的な制約ではありません。このため、別の言語またはバイトコード・ジェネレータには、パッケージ制約に従わない自由があります。

   • それ以外の場合、Cがクラスであり、Cで宣言された非staticメソッドが、Cのスーパークラスで宣言されたfinalの非staticメソッドをオーバーライド(5.4.5)できる場合、導出によってVerifyErrorがスローされます。

     VerifyErrorに関するコメントと同じです。

4. Cに直接スーパーインタフェースがある場合、Cから直接スーパーインタフェースへのシンボリック参照は5.4.3.1のアルゴリズムを使用して解決されます。

   ロード導出のこのフェーズの結果として、クラスまたはインタフェースの解決が原因でスローできる任意の例外をスローできます。また、ロード導出のこのフェーズでは、次のエラーを検出する必要があります。

   • Cの直接スーパーインタフェースとして名前が付けられたクラスまたはインタフェースが実際にインタフェースではない場合、ロードによってIncompatibleClassChangeErrorがスローされます。

   • それ以外の場合、Cの任意のスーパーインタフェースがC自体である場合直接スーパーインタフェースを解決しようとした結果、現在のスレッドがローダーLを使用してNという名前のクラスを再帰的に導出しようとする場合、ロード導出によってClassCircularityErrorがスローされます。

   • それ以外の場合、Cの直接スーパーインタフェースとして名前が付けられたクラスまたはインタフェースが実際にインタフェースではない場合、導出によってIncompatibleClassChangeErrorがスローされます。

   • それ以外の場合、直接スーパーインタフェースごとに、スーパーインタフェースがPermittedSubclasses属性(4.7.30)を持ち、次のいずれかが当てはまる場合、導出は失敗してIncompatibleClassChangeErrorがスローされます。

     • このスーパーインタフェースは、Cとは異なる実行時モジュールに属します。

     • CにはACC_PUBLICフラグ(4.1)が設定されておらず、このスーパーインタフェースは、Cとは異なる実行時パッケージに属します。

     • スーパーインタフェースのPermittedSubclasses属性のclasses表内のエントリが、名前Nを持つクラスまたはインタフェースを参照することはありません。

5. ステップ1以降、別のスレッドで、Java仮想マシンにより、Nという名前のクラスまたはインタフェースが定義側のクラス・ローダーとしてLを持つとマークされた場合、そのクラスまたはインタフェースはクラスの導出の結果であり、ステップ1～4で導出されたクラスまたはインタフェースは破棄されます。

   これは、Hotspotの長期にわたる動作ですが、その仕様にはこれに対する備えはありません。

   それ以外の場合、ステップ1～4で導出されたクラスまたはインタフェースは、クラスの導出の結果であり、Java仮想マシンは、定義側のクラス・ローダーとしてLを持つとしてCをマークし、LをCを開始するローダーとして記録します(5.3.4)。