第4章 classファイル形式

classファイル構造体に出現するクラス名およびインタフェース名は、常にバイナリ名(JLS§13.1)と呼ばれる完全修飾形式で表されます。 このような名前は、常にCONSTANT_Utf8_info構造体(§4.4.7)として表されるため、Unicodeコードスペース全体からさらに制約されないかぎり、描画できます。 クラスおよびインタフェース名は、記述子(§4.3)の一部としてこのような名前を持つCONSTANT_NameAndType_info構造体(§4.4.6)およびすべてのCONSTANT_Class_info構造体(§4.4.1)から参照されます。

過去の理由から、classファイル構造に現れるバイナリ名の構文は、JLS§13.1に記載されているバイナリ名の構文とは異なります。 この内部形式では、通常バイナリ名を構成する識別子を区切るASCIIピリオド(.)は、ASCIIフォワード・スラッシュ(/)に置き換えられます。 識別子自体は修飾されていない名前でなければなりません(§4.2.2)。

たとえば、クラスThreadの通常のバイナリ名はjava.lang.Threadです。 classファイル形式の記述子で使用される内部形式では、クラスThreadの名前への参照は、文字列java/lang/Threadを表すCONSTANT_Utf8_info構造を使用して実装されます。

メソッド、フィールド、ローカル変数および仮パラメータの名前は、非修飾名として格納されます。 修飾されていない名前には、Unicodeコード・ポイントを少なくとも1つ含める必要があり、ASCII文字. ; [ / (ピリオド、セミコロン、左角カッコまたはスラッシュ)を含めることはできません。

メソッド名はさらに制約されるため、特殊なメソッド名<init>および<clinit> (§2.9)を除き、ASCII文字<または> (つまり、左山カッコまたは右山カッコ)を含めることはできません。

<clinit>を参照できるメソッド呼出し命令はなく、invokespecial命令(§invokespecial)のみが<init>を参照できることに注意してください。

Module属性から参照されるモジュール名は、定数プールのCONSTANT_Module_info構造体に格納されます(§4.4.11)。 CONSTANT_Module_info構造は、モジュール名を示すCONSTANT_Utf8_info構造をラップします。 モジュール名は、クラス名やインタフェース名などの内部形式ではエンコードされません。つまり、モジュール名の識別子を区切るASCIIピリオド(.)は、ASCIIフォワード・スラッシュ(/)に置き換えられません。

モジュール名は、次の制約に従って、Unicodeコードスペース全体から描画できます。

Module属性から参照されるパッケージ名は、定数プールのCONSTANT_Package_info構造体に格納されます(§4.4.12)。 CONSTANT_Package_info構造は、内部形式でエンコードされたパッケージ名を表すCONSTANT_Utf8_info構造をラップします。

ディスクリプタは、文法を使用して指定します。 文法は、文字のシーケンスが様々な種類の構文的に正しい記述子を形成する方法を説明する一連のプロダクションです。 文法の末尾記号はfixed widthフォントで表示され、ASCII文字として解釈される必要があります。 非終端記号は、イタリック型で表示されます。 非終端の定義は、定義される非終端の名前とコロンによって導入されます。 非終端の代替定義が1つ以上続きます。

本番環境の右側の構文 {x}は、ゼロ個以上の xを表します。

生産の右側にあるフレーズ(one of)は、次の行または行の各終端記号が代替定義であることを示します。

フィールド記述子は、フィールド、パラメータ、ローカル変数または値のタイプを表します。

ClassNameは、内部形式でエンコードされたバイナリ・クラスまたはインタフェース名を表します(§4.2.1)。

フィールド記述子は、記述子にClassNameと表示されている場合は、クラス名またはインタフェース名を記述します。 これには、ArrayTypeのComponentTypeにネストされたClassNameが含まれます。

表4.3-Aに、フィールド記述子を型として解釈します。 これらの型の意味については、§2.2、§2.3、および §2.4を参照してください。

配列型を表すフィールド記述子は、ディメンションが255以下の型を表す場合にのみ有効です。

メソッド記述子には、メソッドが取得するパラメータのタイプを表す0個以上のパラメータ記述子と、メソッドが返す値のタイプ(ある場合)を表す戻り記述子が含まれます。

文字Vは、メソッドが値を返さないことを示します(結果はvoidです)。

パラメータ記述子または戻り記述子のFieldTypeで名前がClassNameとして表示される場合、メソッド記述子はクラス名またはインタフェース名をメンションします。

Object m(int i, double d, Thread t) {...}

(IDLjava/lang/Thread;)Ljava/lang/Object;

メソッド・ディスクリプタは、合計長が255以下のメソッド・パラメータを表す場合にのみ有効です。この長さには、インスタンス・メソッドまたはインタフェース・メソッド呼出しの場合のthisのコントリビューションが含まれます。 合計長は、個々のパラメータのコントリビューションを合計して計算されます。この場合、long型またはdouble型のパラメータは長さに2つの単位を、他の型のパラメータは1つの単位を寄与します。

メソッド記述子は、記述するメソッドがクラス・メソッドであるかインスタンス・メソッドであるかに関係なく同じです。 インスタンス・メソッドはthisに渡されますが、そのメソッドが呼び出されるオブジェクトへの参照は、意図した引数に加えて、そのファクトはメソッド記述子に反映されません。 thisへの参照は、インスタンス・メソッドを起動するJava Virtual Machine命令(§2.6.1、§4.11)によって暗黙的に渡されます。

CONSTANT_Class_info構造は、クラスまたはインタフェースを表すために使用されます。

CONSTANT_Class_info {
    u1 tag;
    u2 name_index;
}

CONSTANT_Class_info構造の項目は次のとおりです。

配列はオブジェクトであるため、opcode anewarrayおよびmultianewarrayは(ただし、opcode newは)constant_pool表のCONSTANT_Class_info構造体を介して配列「クラス」を参照することはできません。 このような配列クラスの場合、クラスの名前は配列型の記述子になります(§4.3.2)。

配列型記述子は、255以下のディメンションを表す場合にのみ有効です。

フィールド、メソッドおよびインタフェース・メソッドは、次のような構造で表されます。

CONSTANT_Fieldref_info {
    u1 tag;
    u2 class_index;
    u2 name_and_type_index;
}

CONSTANT_Methodref_info {
    u1 tag;
    u2 class_index;
    u2 name_and_type_index;
}

CONSTANT_InterfaceMethodref_info {
    u1 tag;
    u2 class_index;
    u2 name_and_type_index;
}

これらの構造の項目は次のとおりです。

CONSTANT_String_info構造は、String型の定数オブジェクトを表すために使用されます。

CONSTANT_String_info {
    u1 tag;
    u2 string_index;
}

CONSTANT_String_info構造の項目は次のとおりです。

CONSTANT_Integer_infoおよびCONSTANT_Float_info構造は、4バイトの数値(intおよびfloat)定数を表します。

CONSTANT_Integer_info {
    u1 tag;
    u4 bytes;
}

CONSTANT_Float_info {
    u1 tag;
    u4 bytes;
}

これらの構造の項目は次のとおりです。

CONSTANT_Long_infoおよびCONSTANT_Double_infoは、8バイトの数値(longおよびdouble)定数を表します。

CONSTANT_Long_info {
    u1 tag;
    u4 high_bytes;
    u4 low_bytes;
}

CONSTANT_Double_info {
    u1 tag;
    u4 high_bytes;
    u4 low_bytes;
}

8バイトのすべての定数は、classファイルのconstant_pool表の2つのエントリを取ります。 CONSTANT_Long_infoまたはCONSTANT_Double_info構造がconstant_pool表の索引nのエントリである場合、表内の次の使用可能なエントリは索引n+2にあります。 constant_pool索引n+1は有効である必要がありますが、使用不可とみなされます。

振り返ってみると、8バイトの定数のプールエントリを2つ取得することは、不適切な選択でした。

これらの構造の項目は次のとおりです。

CONSTANT_NameAndType_info構造は、フィールドまたはメソッドを表すために使用され、どのクラスまたはインタフェース・タイプに属するかは示されません。

CONSTANT_NameAndType_info {
    u1 tag;
    u2 name_index;
    u2 descriptor_index;
}

CONSTANT_NameAndType_info構造の項目は次のとおりです。

CONSTANT_Utf8_info構造は、定数文字列値を表すために使用されます。

CONSTANT_Utf8_info {
    u1 tag;
    u2 length;
    u1 bytes[length];
}

CONSTANT_Utf8_info構造の項目は次のとおりです。

文字列の内容は、変更されたUTF-8でエンコードされます。 変更されたUTF-8文字列はエンコードされるため、NULL以外のASCII文字のみを含むコード・ポイント・シーケンスは、コード・ポイントごとに1バイトのみを使用して表現できますが、Unicodeコード・スペース内のすべてのコード・ポイントを表現できます。 変更されたUTF-8文字列はNULLで終了しません。 エンコーディングは次のとおりです。

マルチバイト文字のバイトは、classファイルにビッグ・エンディアン(ハイ・バイト・ファースト)の順序で格納されます。

この形式と標準UTF-8形式には2つの違いがあります。 まず、NULL文字(char)0は、1バイト形式ではなく2バイト形式を使用してエンコードされるため、変更されたUTF-8文字列にはNULLが埋め込まれません。 次に、標準 UTF-8の1バイト、2バイト、および3バイト形式のみが使用されます。 Java Virtual Machineは、標準UTF-8の4バイト形式を認識しません。かわりに、独自の2倍3バイト形式を使用します。

標準のUTF-8形式の詳細は、The Unicode Standard、 Version 17.0.0のセクション3.9のUnicodeエンコーディング・フォームを参照してください。

CONSTANT_MethodHandle_info構造は、メソッド・ハンドルを表すために使用されます。

CONSTANT_MethodHandle_info {
    u1 tag;
    u1 reference_kind;
    u2 reference_index;
}

CONSTANT_MethodHandle_info構造の項目は次のとおりです。

CONSTANT_MethodType_info構造は、メソッド・タイプを表すために使用されます。

CONSTANT_MethodType_info {
    u1 tag;
    u2 descriptor_index;
}

CONSTANT_MethodType_info構造の項目は次のとおりです。

constant_pool表のほとんどの構造は、表に静的に記録された名前、記述子および値を組み合せることで、エンティティを直接表します。 これに対して、CONSTANT_Dynamic_infoおよびCONSTANT_InvokeDynamic_info構造は、エンティティを動的に計算するコードを指すことによって、エンティティを間接的に表します。 ブートストラップ・メソッドと呼ばれるコードは、これらの構造から導出されたシンボリック参照の解決中にJava Virtual Machineによって呼び出されます(§5.1、§5.4.3.6)。 各構造体は、ブートストラップ・メソッド、および計算対象のエンティティを特徴付ける補助名とタイプを指定します。 詳細は次のとおりです。

CONSTANT_Dynamic_info {
    u1 tag;
    u2 bootstrap_method_attr_index;
    u2 name_and_type_index;
}

CONSTANT_InvokeDynamic_info {
    u1 tag;
    u2 bootstrap_method_attr_index;
    u2 name_and_type_index;
}

これらの構造の項目は次のとおりです。

CONSTANT_Module_info構造は、モジュールを表すために使用されます。

CONSTANT_Module_info {
    u1 tag;
    u2 name_index;
}

CONSTANT_Module_info構造の項目は次のとおりです。

CONSTANT_Module_info構造は、モジュールを宣言するclassファイルの定数プール、つまり、access_flagsアイテムにACC_MODULEフラグが設定されているClassFile構造体でのみ許可されます。 他のすべてのclassファイルでは、CONSTANT_Module_info構造は不正です。

CONSTANT_Package_info構造は、モジュールによってエクスポートまたはオープンされるパッケージを表すために使用されます。

CONSTANT_Package_info {
    u1 tag;
    u2 name_index;
}

CONSTANT_Package_info構造の項目は次のとおりです。

CONSTANT_Package_info構造は、モジュールを宣言するclassファイルの定数プール、つまり、access_flagsアイテムにACC_MODULEフラグが設定されているClassFile構造体でのみ許可されます。 他のすべてのclassファイルでは、CONSTANT_Package_info構造は不正です。

コンパイラは、classファイル構造、field_info構造、method_info構造およびCode属性(§4.7.3)のattributes表に新しい属性を含むclassファイルを定義および発行できます。 Java Virtual Machineの実装では、これらのattributes表にある新しい属性を認識して使用することが許可されます。 ただし、この仕様の一部として定義されていない属性は、classファイルのセマンティクスに影響を与えません。 Java Virtual Machineの実装は、認識されない属性をサイレントに無視するために必要です。

たとえば、ベンダー固有のデバッグをサポートするための新しい属性の定義が許可されます。 Java Virtual Machineの実装では認識されない属性を無視する必要があるため、その特定のJava Virtual Machine実装を目的としたclassファイルは、classファイルに含まれる追加のデバッグ情報を実装で使用できない場合でも、他の実装で使用できます。

Java Virtual Machineの実装では、単に新しい属性が存在するため、例外をスローしたり、classファイルの使用を拒否したりすることは特に禁止されています。 もちろん、必要なすべての属性が含まれていないclassファイルを指定した場合、classファイルで動作するツールが正しく実行されないことがあります。

同じ属性名を使用し、同じ長さの2つの属性が、どちらかの属性を認識する実装で競合します。 この仕様以外で定義される属性には、The Java Language Specification、 Java SE 26 Edition (JLS§6.1)で説明されているパッケージ命名規則に従って名前を選択する必要があります。

この仕様の将来のバージョンでは、追加属性を定義できます。

ConstantValue属性は、field_info構造(§4.5)のattributes表の固定長属性です。 ConstantValue属性は、定数式(JLS§15.28)の値を表し、次のように使用されます。

field_info構造のattributes表には、最大1つのConstantValue属性を指定できます。

ConstantValue属性の形式は次のとおりです。

ConstantValue_attribute {
    u2 attribute_name_index;
    u4 attribute_length;
    u2 constantvalue_index;
}

ConstantValue_attribute構造の項目は次のとおりです。

Code属性は、method_info構造(§4.6)のattributes表の可変長属性です。 Code属性には、インスタンス初期化メソッド、クラスまたはインタフェース初期化メソッド(§2.9.1、§2.9.2)など、メソッドのJava Virtual Machine命令および補助情報が含まれます。

メソッドがnativeまたはabstractで、クラスまたはインタフェース初期化メソッドではない場合、そのmethod_info構造体のattributes表にCode属性を指定しないでください。 それ以外の場合は、そのmethod_info構造がattributes表に1つのCode属性を持つ必要があります。

Code属性の形式は次のとおりです。

Code_attribute {
    u2 attribute_name_index;
    u4 attribute_length;
    u2 max_stack;
    u2 max_locals;
    u4 code_length;
    u1 code[code_length];
    u2 exception_table_length;
    {   u2 start_pc;
        u2 end_pc;
        u2 handler_pc;
        u2 catch_type;
    } exception_table[exception_table_length];
    u2 attributes_count;
    attribute_info attributes[attributes_count];
}

Code_attribute構造の項目は次のとおりです。

StackMapTable属性は、Code属性(§4.7.3)のattributes表の可変長属性です。 StackMapTable属性は、型チェックによる検証プロセス中に使用されます(§4.10.1)。

Code属性のattributes表には、最大1つのStackMapTable属性を指定できます。

バージョン番号が50.0以上のclassファイルでは、メソッドのCode属性にStackMapTable属性がない場合は、暗黙的スタック・マップ属性(§4.10.1)があります。 この暗黙的なスタック・マップ属性は、number_of_entriesがゼロのStackMapTable属性と同等です。

StackMapTable属性の形式は次のとおりです。

StackMapTable_attribute {
    u2              attribute_name_index;
    u4              attribute_length;
    u2              number_of_entries;
    stack_map_frame entries[number_of_entries];
}

StackMapTable_attribute構造の項目は次のとおりです。

スタック・マップ・フレームは、適用するバイトコード・オフセット、およびそのオフセットに対するローカル変数とオペランド・スタック・エントリの検証タイプ(明示的または暗黙的)を指定します。

entries表で説明されている各スタック・マップ・フレームは、そのセマンティクスの一部について前のフレームに依存しています。 メソッドの最初のスタック・マップ・フレームは暗黙的であり、型チェッカ(§4.10.1.5)によってメソッド記述子から計算されます。 したがって、entries[0]のstack_map_frame構造体は、メソッドの2番目のスタック・マップ・フレームを記述します。

スタック・マップ・フレームが適用されるバイトコード・オフセットは、フレームで指定された値offset_deltaを(明示的または暗黙的に)取得し、前のフレームがメソッドの初期フレームでないかぎり、前のフレームのバイトコード・オフセットにoffset_delta + 1を追加することによって計算されます。 その場合、スタック・マップ・フレームが適用されるバイトコード・オフセットは、フレームで指定された値offset_deltaです。

実際のバイトコードオフセットを格納するのではなく、オフセットデルタを使用することにより、定義上、スタックマップフレームが正しくソートされた順序になるようにします。 さらに、すべての明示的なフレームに対して式offset_delta + 1を一貫して使用することで(暗黙的な最初のフレームとは対照的に)、重複がないことを保証します。

Code属性のcode配列のオフセットiで命令が開始され、Code属性にStackMapTable属性があり、そのentries配列にバイトコード・オフセットiで適用されるスタック・マップ・フレームが含まれている場合は、バイトコード内の命令に対応するスタック・マップ・フレームがあるとします。

検証タイプは、1つまたは2つの場所のタイプを指定します。ここで、場所は、単一のローカル変数または単一のオペランド・スタック・エントリです。 検証タイプは、1バイトのタグで構成される識別ユニオンverification_type_infoによって表され、ユニオンのどのアイテムが使用中かを示し、その後にゼロ以上のバイトが続いて、タグに関する詳細情報を提供します。

union verification_type_info {
    Top_variable_info;
    Integer_variable_info;
    Float_variable_info;
    Long_variable_info;
    Double_variable_info;
    Null_variable_info;
    UninitializedThis_variable_info;
    Object_variable_info;
    Uninitialized_variable_info;
}

ローカル変数配列またはオペランド・スタック内の1つの場所を指定する検証タイプは、verification_type_info共用体の次の項目で表されます。

ローカル変数配列またはオペランド・スタック内の2つの場所を指定する検証タイプは、verification_type_info共用体の次の項目で表されます。

スタック・マップ・フレームは、識別された和集合stack_map_frameで表されます。これは、1バイトのタグで構成され、和集合のどのアイテムが使用中かを示し、その後に0バイト以上が続くため、タグに関する詳細情報を提供します。

union stack_map_frame {
    same_frame;
    same_locals_1_stack_item_frame;
    same_locals_1_stack_item_frame_extended;
    chop_frame;
    same_frame_extended;
    append_frame;
    full_frame;
}

このタグは、スタック・マップ・フレームのフレーム・タイプを示します。

Exceptions属性は、method_info構造(§4.6)のattributes表の可変長属性です。 Exceptions属性は、メソッドがスローする可能性のあるチェック例外を示します。

method_info構造のattributes表には、最大1つのExceptions属性を指定できます。

Exceptions属性の形式は次のとおりです。

Exceptions_attribute {
    u2 attribute_name_index;
    u4 attribute_length;
    u2 number_of_exceptions;
    u2 exception_index_table[number_of_exceptions];
}

Exceptions_attribute構造の項目は次のとおりです。

次の3つの基準のうち少なくとも1つが満たされた場合のみ、メソッドは例外をスローする必要があります。

これらの要件は、Java Virtual Machineでは適用されず、コンパイル時にのみ適用されます。

InnerClasses属性は、ClassFile構造(§4.1)のattributes表の可変長属性です。

クラスまたはインタフェースCの定数プールに、パッケージのメンバーではないクラスまたはインタフェースを表すCONSTANT_Class_infoエントリ(§4.4.1)が少なくとも1つ含まれている場合、CのClassFile構造のattributes表には、InnerClasses属性が1つのみ存在する必要があります。

InnerClasses属性の形式は次のとおりです。

InnerClasses_attribute {
    u2 attribute_name_index;
    u4 attribute_length;
    u2 number_of_classes;
    {   u2 inner_class_info_index;
        u2 outer_class_info_index;
        u2 inner_name_index;
        u2 inner_class_access_flags;
    } classes[number_of_classes];
}

InnerClasses_attribute構造の項目は次のとおりです。

OracleのJava Virtual Machine実装では、属性によって参照されるクラスまたはインタフェースを表すclassファイルに対して、InnerClasses属性の一貫性をチェックしません。

EnclosingMethod属性は、ClassFile構造(§4.1)のattributes表の固定長属性です。 クラスは、ローカル・クラスまたは匿名クラス(JLS§14.3、JLS§15.9.5)を表す場合にのみ、EnclosingMethod属性を持つ必要があります。

ClassFile構造のattributes表には、最大1つのEnclosingMethod属性を指定できます。

EnclosingMethod属性の形式は次のとおりです。

EnclosingMethod_attribute {
    u2 attribute_name_index;
    u4 attribute_length;
    u2 class_index;
    u2 method_index;
}

EnclosingMethod_attribute構造の項目は次のとおりです。

Synthetic属性は、ClassFile、field_infoまたはmethod_info構造(§4.1、§4.5、§4.6)のattributes表の固定長属性です。 ソース・コードに含まれないクラス・メンバーは、Synthetic属性を使用してマークするか、またはACC_SYNTHETICフラグが設定されている必要があります。 この要件に対する唯一の例外は、実装アーティファクトとはみなされないコンパイラ生成メンバーです。次に例を示します。

Synthetic属性は、ネストされたクラスおよびインタフェースをサポートするためにJDK 1.1で導入されました。

これは、仮パラメータおよびモジュールのみにACC_MANDATED (§4.7.24、§4.7.25)のフラグを付けることができるclassファイル形式の制限であり、コンパイラが生成されても実装アーティファクトとはみなされないことを示します。 コンパイラが生成した他の構造体にも、それらが実装アーティファクトとみなされないようにフラグを付ける方法はありません(JLS§13.1)。 この制限は、Java SEプラットフォームのリフレクティブAPIが、このような構成の「必須」ステータスを正確に示していない可能性があることを意味します。

Synthetic属性の形式は次のとおりです。

Synthetic_attribute {
    u2 attribute_name_index;
    u4 attribute_length;
}

Synthetic_attribute構造の項目は次のとおりです。

Signature属性は、ClassFile、field_info、method_infoまたはrecord_component_info構造(§4.1、§4.5、§4.6、§4.7.30)のattributes表の固定長属性です。 Signature属性は、Javaプログラミング言語での宣言で型変数またはパラメータ化された型を使用するクラス、インタフェース、コンストラクタ、メソッド、フィールドまたはレコード・コンポーネントのシグネチャ(§4.7.9.1)を格納します。 これらのコンストラクトの詳細は、Java言語仕様、Java SE 26Editionを参照してください。

ClassFile、field_info、method_infoまたはrecord_component_info構造のattributes表には、最大1つのSignature属性を指定できます。

Signature属性の形式は次のとおりです。

Signature_attribute {
    u2 attribute_name_index;
    u4 attribute_length;
    u2 signature_index;
}

Signature_attribute構造の項目は次のとおりです。

OracleのJava Virtual Machine実装では、クラスのロード中またはリンク中にSignature属性の整形式がチェックされません。 かわりに、Signature属性は、クラス、インタフェース、コンストラクタ、メソッドおよびフィールドの汎用シグネチャを公開するJava SE Platformクラス・ライブラリのメソッドによってチェックされます。 例として、ClassにgetGenericSuperclass、java.lang.reflect.ExecutableにtoGenericStringがあります。

SourceFile属性は、ClassFile構造(§4.1)のattributes表にあるオプションの固定長属性です。

ClassFile構造のattributes表には、最大1つのSourceFile属性を指定できます。

SourceFile属性の形式は次のとおりです。

SourceFile_attribute {
    u2 attribute_name_index;
    u4 attribute_length;
    u2 sourcefile_index;
}

SourceFile_attribute構造の項目は次のとおりです。

SourceDebugExtension属性は、ClassFile構造(§4.1)のattributes表のオプション属性です。

ClassFile構造のattributes表には、最大1つのSourceDebugExtension属性を指定できます。

SourceDebugExtension属性の形式は次のとおりです。

SourceDebugExtension_attribute {
    u2 attribute_name_index;
    u4 attribute_length;
    u1 debug_extension[attribute_length];
}

SourceDebugExtension_attribute構造の項目は次のとおりです。

LineNumberTable属性は、Code属性(§4.7.3)のattributes表にあるオプションの可変長属性です。 デバッガは、code配列のどの部分が元のソース・ファイル内の特定の行番号に対応しているかを判断するために使用できます。

Code属性のattributes表に複数のLineNumberTable属性が存在する場合は、任意の順序で指定できます。

Code属性のattributes表には、ソース・ファイルの1行当たり複数のLineNumberTable属性が存在する場合があります。 つまり、LineNumberTable属性は、ソース・ファイルの特定の行を表す場合があり、ソース行を含む1対1である必要はありません。

LineNumberTable属性の形式は次のとおりです。

LineNumberTable_attribute {
    u2 attribute_name_index;
    u4 attribute_length;
    u2 line_number_table_length;
    {   u2 start_pc;
        u2 line_number;
    } line_number_table[line_number_table_length];
}

LineNumberTable_attribute構造の項目は次のとおりです。

LocalVariableTable属性は、Code属性(§4.7.3)のattributes表にあるオプションの可変長属性です。 メソッドの実行中に、特定のローカル変数の値を決定するためにデバッガが使用できます。

Code属性のattributes表に複数のLocalVariableTable属性が存在する場合は、任意の順序で指定できます。

Code属性のattributes表には、ローカル変数ごとのLocalVariableTable属性が複数存在することはできません。

LocalVariableTable属性の形式は次のとおりです。

LocalVariableTable_attribute {
    u2 attribute_name_index;
    u4 attribute_length;
    u2 local_variable_table_length;
    {   u2 start_pc;
        u2 length;
        u2 name_index;
        u2 descriptor_index;
        u2 index;
    } local_variable_table[local_variable_table_length];
}

LocalVariableTable_attribute構造の項目は次のとおりです。

LocalVariableTypeTable属性は、Code属性(§4.7.3)のattributes表にあるオプションの可変長属性です。 メソッドの実行中に、特定のローカル変数の値を決定するためにデバッガが使用できます。

特定のCode属性のattributes表に複数のLocalVariableTypeTable属性が存在する場合、それらは任意の順序で指定できます。

Code属性のattributes表には、ローカル変数ごとのLocalVariableTypeTable属性が複数存在することはできません。

LocalVariableTypeTable属性は、記述子情報ではなく署名情報を提供する点で、LocalVariableTable属性(§4.7.13)とは異なります。 この違いは、型が型変数またはパラメータ化された型を使用する変数にのみ有効です。 このような変数は両方の表に表示されますが、他の型の変数はLocalVariableTableにのみ表示されます。

LocalVariableTypeTable属性の形式は次のとおりです。

LocalVariableTypeTable_attribute {
    u2 attribute_name_index;
    u4 attribute_length;
    u2 local_variable_type_table_length;
    {   u2 start_pc;
        u2 length;
        u2 name_index;
        u2 signature_index;
        u2 index;
    } local_variable_type_table[local_variable_type_table_length];
}

LocalVariableTypeTable_attribute構造の項目は次のとおりです。