Class and interface names that appear in class file structures are always represented in a fully qualified form known as binary names (JLS §13.1). Such names are always represented as CONSTANT_Utf8_info structures (§4.4.7) and thus may be drawn, where not further constrained, from the entire Unicode codespace. Class and interface names are referenced from those CONSTANT_NameAndType_info structures (§4.4.6) which have such names as part of their descriptor (§4.3), and from all CONSTANT_Class_info structures (§4.4.1).

For historical reasons, the syntax of binary names that appear in class file structures differs from the syntax of binary names documented in JLS §13.1. In this internal form, the ASCII periods (.) that normally separate the identifiers which make up the binary name are replaced by ASCII forward slashes (/). The identifiers themselves must be unqualified names (§4.2.2).

For example, the normal binary name of class Thread is java.lang.Thread. In the internal form used in descriptors in the class file format, a reference to the name of class Thread is implemented using a CONSTANT_Utf8_info structure representing the string java/lang/Thread.

Names of methods, fields, and local variables are stored as unqualified names. An unqualified name must not contain any of the ASCII characters . ; [ / (that is, period or semicolon or left square bracket or forward slash).

Method names are further constrained so that, with the exception of the special method names <init> and <clinit> (§2.9), they must not contain the ASCII characters < or > (that is, left angle bracket or right angle bracket).

Note that a field name or interface method name may be <init> or <clinit>, but no method invocation instruction may reference <clinit> and only the invokespecial instruction (§invokespecial) may reference <init>.

Descriptors and signatures are specified using a grammar. This grammar is a set of productions that describe how sequences of characters can form syntactically correct descriptors of various types. Terminal symbols of the grammar are shown in bold fixed-width font. Nonterminal symbols are shown in italic type. The definition of a nonterminal is introduced by the name of the nonterminal being defined, followed by a colon. One or more alternative right-hand sides for the nonterminal then follow on succeeding lines. For example, the production:

states that a FieldType may represent either a BaseType, an ObjectType or an ArrayType.

A nonterminal symbol on the right-hand side of a production that is followed by an asterisk (*) represents zero or more possibly different values produced from that nonterminal, appended without any intervening space. Similarly, a nonterminal symbol on the right-hand side of a production that is followed by an plus sign (+) represents one or more possibly different values produced from that nonterminal, appended without any intervening space. The production:

states that a MethodDescriptor represents a left parenthesis, followed by zero or more ParameterDescriptor values, followed by a right parenthesis, followed by a ReturnDescriptor.

A field descriptor represents the type of a class, instance, or local variable. It is a series of characters generated by the grammar:

The characters of BaseType, the L and ; of ObjectType, and the [ of ArrayType are all ASCII characters.

The ClassName represents a binary class or interface name encoded in internal form (§4.2.1).

The interpretation of field descriptors as types is as shown in Table 4.2.

A field descriptor representing an array type is valid only if it represents a type with 255 or fewer dimensions.

A method descriptor represents the parameters that the method takes and the value that it returns:

A parameter descriptor represents a parameter passed to a method:

A return descriptor represents the type of the value returned from a method. It is a series of characters generated by the grammar:

The character V indicates that the method returns no value (its return type is void).

A method descriptor is valid only if it represents method parameters with a total length of 255 or less, where that length includes the contribution for this in the case of instance or interface method invocations. The total length is calculated by summing the contributions of the individual parameters, where a parameter of type long or double contributes two units to the length and a parameter of any other type contributes one unit.

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

Signatures are used to encode Java programming language type information that is not part of the Java Virtual Machine type system, such as generic type and method declarations and parameterized types. See The Java Language Specification, Java SE 7 Edition for details about such types.

This kind of type information is needed to support reflection and debugging, and by a Java compiler.

In the following, the terminal symbol Identifier is used to denote the name of a type, field, local variable, parameter, method, or type variable, as generated by a Java compiler. Such a name must not contain any of the ASCII characters . ; [ / < > : (that is, the characters forbidden in method names (§4.2.2) and also colon) but may contain characters that must not appear in an identifier in the Java programming language (JLS §3.8).

A class signature, defined by the production ClassSignature, is used to encode type information about a class declaration. It describes any formal type parameters the class might have, and lists its (possibly parameterized) direct superclass and direct superinterfaces, if any.

A formal type parameter is described by its name, followed by its class and interface bounds. If the class bound does not specify a type, it is taken to be Object.

A field type signature, defined by the production FieldTypeSignature, encodes the (possibly parameterized) type for a field, parameter or local variable.

A class type signature gives complete type information for a class or interface type. The class type signature must be formulated such that it can be reliably mapped to the binary name of the class it denotes by erasing any type arguments and converting each . character in the signature to a $ character.

A method signature, defined by the production MethodTypeSignature, encodes the (possibly parameterized) types of the method's formal arguments and of the exceptions it has declared in its throws clause, its (possibly parameterized) return type, and any formal type parameters in the method declaration.

If the throws clause of a method or constructor does not involve type variables, the ThowsSignature may be elided from the MethodTypeSignature.

A Java compiler must output generic signature information for any class, interface, constructor or member whose generic signature in the Java programming language would include references to type variables or parameterized types.

The signature and descriptor (§4.3.3) of a given method or constructor may not correspond exactly, due to compiler-generated artifacts. In particular, the number of TypeSignatures that encode formal arguments in MethodTypeSignature may be less than the number of ParameterDescriptors in MethodDescriptor.

Oracle's Java Virtual Machine implementation does not check the well-formedness of the signatures described in this subsection during loading or linking. Instead, these checks are deferred until the signatures are used by reflective methods, as specified in the API of Class and members of java.lang.reflect. Future versions of a Java Virtual Machine implementation may be required to perform some or all of these checks during loading or linking.

The CONSTANT_Class_info structure is used to represent a class or an interface:

 CONSTANT_Class_info { u1 tag; u2 name_index; } 

The items of the CONSTANT_Class_info structure are the following:

Because arrays are objects, the opcodes anewarray and multianewarray can reference array "classes" via CONSTANT_Class_info structures in the constant_pool table. For such array classes, the name of the class is the descriptor of the array type.

 int[][] 

 [[I 

 Thread[] 

 [Ljava/lang/Thread; 

An array type descriptor is valid only if it represents 255 or fewer dimensions.

Fields, methods, and interface methods are represented by similar structures:

 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; } 

The items of these structures are as follows:

The CONSTANT_String_info structure is used to represent constant objects of the type String:

 CONSTANT_String_info { u1 tag; u2 string_index; } 

The items of the CONSTANT_String_info structure are as follows:

The CONSTANT_Integer_info and CONSTANT_Float_info structures represent 4-byte numeric (int and float) constants:

 CONSTANT_Integer_info { u1 tag; u4 bytes; } CONSTANT_Float_info { u1 tag; u4 bytes; } 

The items of these structures are as follows:

The CONSTANT_Long_info and CONSTANT_Double_info represent 8-byte numeric (long and double) constants:

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

All 8-byte constants take up two entries in the constant_pool table of the class file. If a CONSTANT_Long_info or CONSTANT_Double_info structure is the item in the constant_pool table at index n, then the next usable item in the pool is located at index n+2. The constant_pool index n+1 must be valid but is considered unusable.

In retrospect, making 8-byte constants take two constant pool entries was a poor choice.

The items of these structures are as follows:

The CONSTANT_NameAndType_info structure is used to represent a field or method, without indicating which class or interface type it belongs to:

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

The items of the CONSTANT_NameAndType_info structure are as follows:

The CONSTANT_Utf8_info structure is used to represent constant string values:

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

The items of the CONSTANT_Utf8_info structure are the following:

String content is encoded in modified UTF-8. Modified UTF-8 strings are encoded so that code point sequences that contain only non-null ASCII characters can be represented using only 1 byte per code point, but all code points in the Unicode codespace can be represented.

The bytes of multibyte characters are stored in the class file in big-endian (high byte first) order.

There are two differences between this format and the "standard" UTF-8 format. First, the null character (char)0 is encoded using the 2-byte format rather than the 1-byte format, so that modified UTF-8 strings never have embedded nulls. Second, only the 1-byte, 2-byte, and 3-byte formats of standard UTF-8 are used. The Java Virtual Machine does not recognize the four-byte format of standard UTF-8; it uses its own two-times-three-byte format instead.

For more information regarding the standard UTF-8 format, see Section 3.9 Unicode Encoding Forms of The Unicode Standard, Version 6.0.0.

The CONSTANT_MethodHandle_info structure is used to represent a method handle:

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

The items of the CONSTANT_MethodHandle_info structure are the following:

The CONSTANT_MethodType_info structure is used to represent a method type:

 CONSTANT_MethodType_info { u1 tag; u2 descriptor_index; } 

The items of the CONSTANT_MethodType_info structure are as follows:

The CONSTANT_InvokeDynamic_info structure is used by an invokedynamic instruction (§invokedynamic) to specify a bootstrap method, the dynamic invocation name, the argument and return types of the call, and optionally, a sequence of additional constants called static arguments to the bootstrap method.

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

The items of the CONSTANT_InvokeDynamic_info structure are as follows:

Compilers are permitted to define and emit class files containing new attributes in the attributes tables of class file structures. Java Virtual Machine implementations are permitted to recognize and use new attributes found in the attributes tables of class file structures. However, any attribute not defined as part of this Java Virtual Machine specification must not affect the semantics of class or interface types. Java Virtual Machine implementations are required to silently ignore attributes they do not recognize.

For instance, defining a new attribute to support vendor-specific debugging is permitted. Because Java Virtual Machine implementations are required to ignore attributes they do not recognize, class files intended for that particular Java Virtual Machine implementation will be usable by other implementations even if those implementations cannot make use of the additional debugging information that the class files contain.

Java Virtual Machine implementations are specifically prohibited from throwing an exception or otherwise refusing to use class files simply because of the presence of some new attribute. Of course, tools operating on class files may not run correctly if given class files that do not contain all the attributes they require.

Two attributes that are intended to be distinct, but that happen to use the same attribute name and are of the same length, will conflict on implementations that recognize either attribute. Attributes defined other than in this specification must have names chosen according to the package naming convention described in The Java Language Specification, Java SE 7 Edition (JLS §6.1).

Future versions of this specification may define additional attributes.

The ConstantValue attribute is a fixed-length attribute in the attributes table of a field_info structure (§4.5). A ConstantValue attribute represents the value of a constant field. There can be no more than one ConstantValue attribute in the attributes table of a given field_info structure. If the field is static (that is, the ACC_STATIC flag (Table 4.4) in the access_flags item of the field_info structure is set) then the constant field represented by the field_info structure is assigned the value referenced by its ConstantValue attribute as part of the initialization of the class or interface declaring the constant field (§5.5). This occurs prior to the invocation of the class or interface initialization method (§2.9) of that class or interface.

If a field_info structure representing a non-static field has a ConstantValue attribute, then that attribute must silently be ignored. Every Java Virtual Machine implementation must recognize ConstantValue attributes.

The ConstantValue attribute has the following format:

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

The items of the ConstantValue_attribute structure are as follows:

The Code attribute is a variable-length attribute in the attributes table of a method_info (§4.6) structure. A Code attribute contains the Java Virtual Machine instructions and auxiliary information for a single method, instance initialization method (§2.9), or class or interface initialization method (§2.9). Every Java Virtual Machine implementation must recognize Code attributes. If the method is either native or abstract, its method_info structure must not have a Code attribute. Otherwise, its method_info structure must have exactly one Code attribute.

The Code attribute has the following format:

 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]; } 

The items of the Code_attribute structure are as follows:

The StackMapTable attribute is a variable-length attribute in the attributes table of a Code (§4.7.3) attribute. This attribute is used during the process of verification by type checking (§4.10.1). A method's Code attribute may have at most one StackMapTable attribute.

A StackMapTable attribute consists of zero or more stack map frames. Each stack map frame specifies (either explicitly or implicitly) a bytecode offset, the verification types (§4.10.1.2) for the local variables, and the verification types for the operand stack.

The type checker deals with and manipulates the expected types of a method's local variables and operand stack. Throughout this section, a location refers to either a single local variable or to a single operand stack entry.

We will use the terms stack map frame and type state interchangeably to describe a mapping from locations in the operand stack and local variables of a method to verification types. We will usually use the term stack map frame when such a mapping is provided in the class file, and the term type state when the mapping is used by the type checker.

In a class file whose version number is greater than or equal to 50.0, if a method's Code attribute does not have a StackMapTable attribute, it has an implicit stack map attribute. This implicit stack map attribute is equivalent to a StackMapTable attribute with number_of_entries equal to zero.

The StackMapTable attribute has the following format:

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

The items of the StackMapTable_attribute structure are as follows:

Each stack_map_frame structure specifies the type state at a particular bytecode offset. Each frame type specifies (explicitly or implicitly) a value, offset_delta, that is used to calculate the actual bytecode offset at which a frame applies. The bytecode offset at which a frame applies is calculated by adding offset_delta + 1 to the bytecode offset of the previous frame, unless the previous frame is the initial frame of the method, in which case the bytecode offset is offset_delta.

By using an offset delta rather than the actual bytecode offset we ensure, by definition, that stack map frames are in the correctly sorted order. Furthermore, by consistently using the formula offset_delta + 1 for all explicit frames, we guarantee the absence of duplicates.

We say that an instruction in the bytecode has a corresponding stack map frame if the instruction starts at offset i in the code array of a Code attribute, and the Code attribute has a StackMapTable attribute whose entries array has a stack_map_frame structure that applies at bytecode offset i.

The stack_map_frame structure consists of a one-byte tag followed by zero or more bytes, giving more information, depending upon the tag.

A stack map frame may belong to one of several frame types:

 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; } 

All frame types, even full_frame, rely on the previous frame for some of their semantics. This raises the question of what is the very first frame? The initial frame is implicit, and computed from the method descriptor. (See the Prolog predicate methodInitialStackFrame (§4.10.1.6).)

The verification_type_info structure consists of a one-byte tag followed by zero or more bytes, giving more information about the tag. Each verification_type_info structure specifies the verification type of one or two locations.

 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; } 

The Exceptions attribute is a variable-length attribute in the attributes table of a method_info structure (§4.6). The Exceptions attribute indicates which checked exceptions a method may throw. There may be at most one Exceptions attribute in each method_info structure.

The Exceptions attribute has the following format:

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

The items of the Exceptions_attribute structure are as follows:

A method should throw an exception only if at least one of the following three criteria is met:

These requirements are not enforced in the Java Virtual Machine; they are enforced only at compile-time.

The InnerClasses attribute is a variable-length attribute in the attributes table of a ClassFile structure (§4.1). If the constant pool of a class or interface C contains a CONSTANT_Class_info entry which represents a class or interface that is not a member of a package, then C's ClassFile structure must have exactly one InnerClasses attribute in its attributes table.

The InnerClasses attribute has the following format:

 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]; } 

The items of the InnerClasses_attribute structure are as follows:

Oracle's Java Virtual Machine implementation does not check the consistency of an InnerClasses attribute against a class file representing a class or interface referenced by the attribute.

The EnclosingMethod attribute is an optional fixed-length attribute in the attributes table of a ClassFile structure (§4.1). A class must have an EnclosingMethod attribute if and only if it is a local class or an anonymous class. A class may have no more than one EnclosingMethod attribute.

The EnclosingMethod attribute has the following format:

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

The items of the EnclosingMethod_attribute structure are as follows:

The Synthetic attribute is a fixed-length attribute in the attributes table of a ClassFile, field_info, or method_info structure (§4.1, §4.5, §4.6). A class member that does not appear in the source code must be marked using a Synthetic attribute, or else it must have its ACC_SYNTHETIC flag set. The only exceptions to this requirement are compiler-generated methods which are not considered implementation artifacts, namely the instance initialization method representing a default constructor of the Java programming language (§2.9), the class initialization method (§2.9), and the Enum.values() and Enum.valueOf() methods.

The Synthetic attribute was introduced in JDK release 1.1 to support nested classes and interfaces.

The Synthetic attribute has the following format:

 Synthetic_attribute { u2 attribute_name_index; u4 attribute_length; } 

The items of the Synthetic_attribute structure are as follows:

The Signature attribute is an optional fixed-length attribute in the attributes table of a ClassFile, field_info, or method_info structure (§4.1, §4.5, §4.6). The Signature attribute records generic signature information for any class, interface, constructor or member whose generic signature in the Java programming language would include references to type variables or parameterized types.

The Signature attribute has the following format:

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

The items of the Signature_attribute structure are as follows:

The SourceFile attribute is an optional fixed-length attribute in the attributes table of a ClassFile structure (§4.1). There can be no more than one SourceFile attribute in the attributes table of a given ClassFile structure.

The SourceFile attribute has the following format:

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

The items of the SourceFile_attribute structure are as follows:

The SourceDebugExtension attribute is an optional attribute in the attributes table of a ClassFile structure (§4.1). There can be no more than one SourceDebugExtension attribute in the attributes table of a given ClassFile structure.

The SourceDebugExtension attribute has the following format:

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

The items of the SourceDebugExtension_attribute structure are as follows:

The LineNumberTable attribute is an optional variable-length attribute in the attributes table of a Code (§4.7.3) attribute. It may be used by debuggers to determine which part of the Java Virtual Machine code array corresponds to a given line number in the original source file.

If LineNumberTable attributes are present in the attributes table of a given Code attribute, then they may appear in any order. Furthermore, multiple LineNumberTable attributes may together represent a given line of a source file; that is, LineNumberTable attributes need not be one-to-one with source lines.

The LineNumberTable attribute has the following format:

 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]; } 

The items of the LineNumberTable_attribute structure are as follows:

The LocalVariableTable attribute is an optional variable-length attribute in the attributes table of a Code (§4.7.3) attribute. It may be used by debuggers to determine the value of a given local variable during the execution of a method.

If LocalVariableTable attributes are present in the attributes table of a given Code attribute, then they may appear in any order. There may be no more than one LocalVariableTable attribute per local variable in the Code attribute.

The LocalVariableTable attribute has the following format:

 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]; } 

The items of the LocalVariableTable_attribute structure are as follows:

The LocalVariableTypeTable attribute is an optional variable-length attribute in the attributes table of a Code (§4.7.3) attribute. It may be used by debuggers to determine the value of a given local variable during the execution of a method.

If LocalVariableTypeTable attributes are present in the attributes table of a given Code attribute, then they may appear in any order. There may be no more than one LocalVariableTypeTable attribute per local variable in the Code attribute.

The LocalVariableTypeTable attribute differs from the LocalVariableTable attribute in that it provides signature information rather than descriptor information. This difference is only significant for variables whose type is a generic reference type. Such variables will appear in both tables, while variables of other types will appear only in LocalVariableTable.

The LocalVariableTypeTable attribute has the following format:

 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]; } 

The items of the LocalVariableTypeTable_attribute structure are as follows:

The Deprecated attribute is an optional fixed-length attribute in the attributes table of a ClassFile, field_info, or method_info structure (§4.1, §4.5, §4.6). A class, interface, method, or field may be marked using a Deprecated attribute to indicate that the class, interface, method, or field has been superseded.

A run-time interpreter or tool that reads the class file format, such as a compiler, can use this marking to advise the user that a superceded class, interface, method, or field is being referred to. The presence of a Deprecated attribute does not alter the semantics of a class or interface.

The Deprecated attribute has the following format:

 Deprecated_attribute { u2 attribute_name_index; u4 attribute_length; } 

The items of the Deprecated_attribute structure are as follows:

The RuntimeVisibleAnnotations attribute is a variable-length attribute in the attributes table of a ClassFile, field_info, or method_info structure (§4.1, §4.5, §4.6). The RuntimeVisibleAnnotations attribute records run-time-visible Java programming language annotations on the corresponding class, field, or method.

Each ClassFile, field_info, and method_info structure may contain at most one RuntimeVisibleAnnotations attribute, which records all the run-time-visible Java programming language annotations on the corresponding program element. The Java Virtual Machine must make these annotations available so they can be returned by the appropriate reflective APIs.

The RuntimeVisibleAnnotations attribute has the following format:

 RuntimeVisibleAnnotations_attribute { u2 attribute_name_index; u4 attribute_length; u2 num_annotations; annotation annotations[num_annotations]; } 

The items of the RuntimeVisibleAnnotations_attribute structure are as follows:

 element_value { u1 tag; union { u2 const_value_index; { u2 type_name_index; u2 const_name_index; } enum_const_value; u2 class_info_index; annotation annotation_value; { u2 num_values; element_value values[num_values]; } array_value; } value; } 

The RuntimeInvisibleAnnotations attribute is similar to the RuntimeVisibleAnnotations attribute, except that the annotations represented by a RuntimeInvisibleAnnotations attribute must not be made available for return by reflective APIs, unless the Java Virtual Machine has been instructed to retain these annotations via some implementation-specific mechanism such as a command line flag. In the absence of such instructions, the Java Virtual Machine ignores this attribute.

The RuntimeInvisibleAnnotations attribute is a variable-length attribute in the attributes table of a ClassFile, field_info, or method_info structure (§4.1, §4.5, §4.6). The RuntimeInvisibleAnnotations attribute records run-time-invisible Java programming language annotations on the corresponding class, method, or field.

Each ClassFile, field_info, and method_info structure may contain at most one RuntimeInvisibleAnnotations attribute, which records all the run-time-invisible Java programming language annotations on the corresponding program element.

The RuntimeInvisibleAnnotations attribute has the following format:

 RuntimeInvisibleAnnotations_attribute { u2 attribute_name_index; u4 attribute_length; u2 num_annotations; annotation annotations[num_annotations]; } 

The items of the RuntimeInvisibleAnnotations_attribute structure are as follows:

The RuntimeVisibleParameterAnnotations attribute is a variable-length attribute in the attributes table of the method_info structure (§4.6). The RuntimeVisibleParameterAnnotations attribute records run-time-visible Java programming language annotations on the parameters of the corresponding method.

Each method_info structure may contain at most one RuntimeVisibleParameterAnnotations attribute, which records all the run-time-visible Java programming language annotations on the parameters of the corresponding method. The Java Virtual Machine must make these annotations available so they can be returned by the appropriate reflective APIs.

The RuntimeVisibleParameterAnnotations attribute has the following format:

 RuntimeVisibleParameterAnnotations_attribute { u2 attribute_name_index; u4 attribute_length; u1 num_parameters; { u2 num_annotations; annotation annotations[num_annotations]; } parameter_annotations[num_parameters]; } 

The items of the RuntimeVisibleParameterAnnotations_attribute structure are as follows:

The RuntimeInvisibleParameterAnnotations attribute is similar to the RuntimeVisibleParameterAnnotations attribute, except that the annotations represented by a RuntimeInvisibleParameterAnnotations attribute must not be made available for return by reflective APIs, unless the Java Virtual Machine has specifically been instructed to retain these annotations via some implementation-specific mechanism such as a command line flag. In the absence of such instructions, the Java Virtual Machine ignores this attribute.

The RuntimeInvisibleParameterAnnotations attribute is a variable-length attribute in the attributes table of a method_info structure (§4.6). The RuntimeInvisibleParameterAnnotations attribute records run-time-invisible Java programming language annotations on the parameters of the corresponding method.

Each method_info structure may contain at most one RuntimeInvisibleParameterAnnotations attribute, which records all the run-time-invisible Java programming language annotations on the parameters of the corresponding method.

The RuntimeInvisibleParameterAnnotations attribute has the following format:

 RuntimeInvisibleParameterAnnotations_attribute { u2 attribute_name_index; u4 attribute_length; u1 num_parameters; { u2 num_annotations; annotation annotations[num_annotations]; } parameter_annotations[num_parameters]; } 

The items of the RuntimeInvisibleParameterAnnotations_attribute structure are as follows:

The AnnotationDefault attribute is a variable-length attribute in the attributes table of certain method_info structures (§4.6), namely those representing elements of annotation types. The AnnotationDefault attribute records the default value for the element represented by the method_info structure.

Each method_info structure representing an element of an annotation type may contain at most one AnnotationDefault attribute. The Java Virtual Machine must make this default value available so it can be applied by appropriate reflective APIs.

The AnnotationDefault attribute has the following format:

 AnnotationDefault_attribute { u2 attribute_name_index; u4 attribute_length; element_value default_value; } 

The items of the AnnotationDefault_attribute structure are as follows:

The BootstrapMethods attribute is a variable-length attribute in the attributes table of a ClassFile structure (§4.1). The BootstrapMethods attribute records bootstrap method specifiers referenced by invokedynamic instructions (§invokedynamic).

There must be exactly one BootstrapMethods attribute in the attributes table of a given ClassFile structure if the constant_pool table of the ClassFile structure has at least one CONSTANT_InvokeDynamic_info entry (§4.4.10). There can be no more than one BootstrapMethods attribute in the attributes table of a given ClassFile structure.

The BootstrapMethods attribute has the following format:

 BootstrapMethods_attribute { u2 attribute_name_index; u4 attribute_length; u2 num_bootstrap_methods; { u2 bootstrap_method_ref; u2 num_bootstrap_arguments; u2 bootstrap_arguments[num_bootstrap_arguments]; } bootstrap_methods[num_bootstrap_methods]; } 

The items of the BootstrapMethods_attribute structure are as follows:

The static constraints on a class file are those defining the well-formedness of the file. With the exception of the static constraints on the Java Virtual Machine code of the class file, these constraints have been given in the previous sections. The static constraints on the Java Virtual Machine code in a class file specify how Java Virtual Machine instructions must be laid out in the code array and what the operands of individual instructions must be.

The static constraints on the instructions in the code array are as follows:

The static constraints on the operands of instructions in the code array are as follows:

The structural constraints on the code array specify constraints on relationships between Java Virtual Machine instructions. The structural constraints are as follows:

A class file whose version number is greater than or equal to 50.0 (§4.1) must be verified using the type checking rules given in this section.

If, and only if, a class file's version number equals 50.0, then if the type checking fails, a Java Virtual Machine implementation may choose to attempt to perform verification by type inference (§4.10.2).

This is a pragmatic adjustment, designed to ease the transition to the new verification discipline. Many tools that manipulate class files may alter the bytecodes of a method in a manner that requires adjustment of the method's stack map frames. If a tool does not make the necessary adjustments to the stack map frames, type checking may fail even though the bytecode is in principle valid (and would consequently verify under the old type inference scheme). To allow implementors time to adapt their tools, Java Virtual Machine implementations may fall back to the older verification discipline, but only for a limited time.

In cases where type checking fails but type inference is invoked and succeeds, a certain performance penalty is expected. Such a penalty is unavoidable. It also should serve as a signal to tool vendors that their output needs to be adjusted, and provides vendors with additional incentive to make these adjustments.

In summary, failover to verification by type inference supports both the gradual addition of stack map frames to the Java SE platform (if they are not present in a version 50.0 class file, failover is allowed) and the gradual removal of the jsr and jsr_w instructions from the Java SE platform (if they are present in a version 50.0 class file, failover is allowed).

If a Java Virtual Machine implementation ever attempts to perform verification by type inference on version 50.0 class files, it must do so in all cases where verification by type checking fails.

This means that a Java Virtual Machine implementation cannot choose to resort to type inference in once case and not in another. It must either reject class files that do not verify via type checking, or else consistently failover to the type inferencing verifier whenever type checking fails.

The type checker enforces type rules that are specified by means of Prolog clauses. English language text is used to describe the type rules in an informal way, while the Prolog clauses provide a formal specification.

The type checker requires a list of stack map frames for each method with a Code attribute (§4.7.3). A list of stack map frames is given by the StackMapTable attribute (§4.7.4) of a Code attribute. The intent is that a stack map frame must appear at the beginning of each basic block in a method. The stack map frame specifies the verification type of each operand stack entry and of each local variable at the start of each basic block. The type checker reads the stack map frames for each method with a Code attribute and uses these maps to generate a proof of the type safety of the instructions in the Code attribute.

A class is type safe if all its methods are type safe, and it does not subclass a final class.

 classIsTypeSafe(Class) :- classClassName(Class, Name), classDefiningLoader(Class, L), superclassChain(Name, L, Chain), Chain \= [], classSuperClassName(Class, SuperclassName), loadedClass(SuperclassName, L, Superclass), classIsNotFinal(Superclass), classMethods(Class, Methods), checklist(methodIsTypeSafe(Class), Methods). 

 classIsTypeSafe(Class) :- classClassName(Class, 'java/lang/Object'), classDefiningLoader(Class, L), isBootstrapLoader(L), classMethods(Class, Methods), checklist(methodIsTypeSafe(Class), Methods). 

The Prolog predicate classIsTypeSafe assumes that Class is a Prolog term representing a binary class that has been successfully parsed and loaded. This specification does not mandate the precise structure of this term, but does require that certain predicates be defined upon it.

For example, we assume a predicate classMethods(Class, Methods) that, given a term representing a class as described above as its first argument, binds its second argument to a list comprising all the methods of the class, represented in a convenient form described later.

Iff the predicate classIsTypeSafe is not true, the type checker must throw the exception VerifyError to indicate that the class file is malformed. Otherwise, the class file has type checked successfully and bytecode verification has completed successfully.

The rest of this section explains the process of type checking in detail:

 allInstructions(Environment, Instructions) :- Environment = environment(_Class, _Method, _ReturnType, Instructions, _, _). exceptionHandlers(Environment, Handlers) :- Environment = environment(_Class, _Method, _ReturnType, _Instructions, _, Handlers). maxOperandStackLength(Environment, MaxStack) :- Environment = environment(_Class, _Method, _ReturnType, _Instructions, MaxStack, _Handlers). thisClass(Environment, class(ClassName, L)) :- Environment = environment(Class, _Method, _ReturnType, _Instructions, _, _), classDefiningLoader(Class, L), classClassName(Class, ClassName). thisMethodReturnType(Environment, ReturnType) :- Environment = environment(_Class, _Method, ReturnType, _Instructions, _, _). 

 offsetStackFrame(Environment, Offset, StackFrame) :- allInstructions(Environment, Instructions), member(stackMap(Offset, StackFrame), Instructions). currentClassLoader(Environment, Loader) :- thisClass(Environment, class(_, Loader)). 

 notMember(_, []). notMember(X, [A | More]) :- X \= A, notMember(X, More). 

 Verification type hierarchy: top ____________/\____________ / \ / \ oneWord twoWord / | \ / \ / | \ / \ int float reference long double / \ / \____________ / \ / \ uninitialized Object / \ \ / \ \ uninitializedThis uninitialized(offset) +------------------+ | Java reference | | type hierarchy | +------------------+ | | null 

 isAssignable(X, X). 

 isAssignable(v, X) :- isAssignable(the_direct_supertype_of_v, X). 

 isAssignable(oneWord, top). isAssignable(twoWord, top). isAssignable(int, X) :- isAssignable(oneWord, X). isAssignable(float, X) :- isAssignable(oneWord, X). isAssignable(long, X) :- isAssignable(twoWord, X). isAssignable(double, X) :- isAssignable(twoWord, X). isAssignable(reference, X) :- isAssignable(oneWord, X). isAssignable(class(_, _), X) :- isAssignable(reference, X). isAssignable(arrayOf(_), X) :- isAssignable(reference, X). isAssignable(uninitialized, X) :- isAssignable(reference, X). isAssignable(uninitializedThis, X) :- isAssignable(uninitialized, X). isAssignable(uninitialized(_), X) :- isAssignable(uninitialized, X). isAssignable(null, class(_, _)). isAssignable(null, arrayOf(_)). isAssignable(null, X) :- isAssignable(class('java/lang/Object', BL), X), isBootstrapLoader(BL). 

 isAssignable(class(X, Lx), class(Y, Ly)) :- isJavaAssignable(class(X, Lx), class(Y, Ly)). isAssignable(arrayOf(X), class(Y, L)) :- isJavaAssignable(arrayOf(X), class(Y, L)). isAssignable(arrayOf(X), arrayOf(Y)) :- isJavaAssignable(arrayOf(X), arrayOf(Y)). 

 isJavaAssignable(class(_, _), class(To, L)) :- loadedClass(To, L, ToClass), classIsInterface(ToClass). isJavaAssignable(From, To) :- isJavaSubclassOf(From, To). 

 isJavaAssignable(arrayOf(_), class('java/lang/Object', BL)) :- isBootstrapLoader(BL). isJavaAssignable(arrayOf(_), X) :- isArrayInterface(X). isArrayInterface(class('java/lang/Cloneable', BL)) :- isBootstrapLoader(BL). isArrayInterface(class('java/io/Serializable', BL)) :- isBootstrapLoader(BL). 

 isJavaAssignable(arrayOf(X), arrayOf(Y)) :- atom(X), atom(Y), X = Y. 

 isJavaAssignable(arrayOf(X), arrayOf(Y)) :- compound(X), compound(Y), isJavaAssignable(X, Y). 

 isJavaSubclassOf(class(SubclassName, L), class(SubclassName, L)). 

 isJavaSubclassOf(class(SubclassName, LSub), class(SuperclassName, LSuper)) :- superclassChain(SubclassName, LSub, Chain), member(class(SuperclassName, L), Chain), loadedClass(SuperclassName, L, Sup), loadedClass(SuperclassName, LSuper, Sup). superclassChain(ClassName, L, [class(SuperclassName, Ls) | Rest]) :- loadedClass(ClassName, L, Class), classSuperClassName(Class, SuperclassName), classDefiningLoader(Class, Ls), superclassChain(SuperclassName, Ls, Rest). superclassChain('java/lang/Object', L, []) :- loadedClass('java/lang/Object', L, Class), classDefiningLoader(Class, BL), isBootstrapLoader(BL). 

 instruction(Offset, AnInstruction) 

 stackMap(Offset, TypeState) 

 frame(Locals, OperandStack, Flags) 

 frameIsAssignable(frame(Locals1, StackMap1, Flags1), frame(Locals2, StackMap2, Flags2)) :- length(StackMap1, StackMapLength), length(StackMap2, StackMapLength), maplist(isAssignable, Locals1, Locals2), maplist(isAssignable, StackMap1, StackMap2), subset(Flags1, Flags2). 

 operandStackHasLegalLength(Environment, OperandStack) :- length(OperandStack, Length), maxOperandStackLength(Environment, MaxStack), Length =< MaxStack. 

 nth1OperandStackIs(I, frame(_Locals, OperandStack, _Flags), Element) :- nth1(I, OperandStack, Element). 

 canPop(frame(Locals, OperandStack, Flags), Types, frame(Locals, PoppedOperandStack, Flags)) :- popMatchingList(OperandStack, Types, PoppedOperandStack). popMatchingList(OperandStack, [], OperandStack). popMatchingList(OperandStack, [P | Rest], NewOperandStack) :- popMatchingType(OperandStack, P, TempOperandStack, _ActualType), popMatchingList(TempOperandStack, Rest, NewOperandStack). 

 popMatchingType([ActualType | OperandStack], Type, OperandStack, ActualType) :- sizeOf(Type, 1), isAssignable(ActualType, Type). popMatchingType([top, ActualType | OperandStack], Type, OperandStack, ActualType) :- sizeOf(Type, 2), isAssignable(ActualType, Type). sizeOf(X, 2) :- isAssignable(X, twoWord). sizeOf(X, 1) :- isAssignable(X, oneWord). sizeOf(top, 1). 

 pushOperandStack(OperandStack, 'void', OperandStack). pushOperandStack(OperandStack, Type, [Type | OperandStack]) :- sizeOf(Type, 1). pushOperandStack(OperandStack, Type, [top, Type | OperandStack]) :- sizeOf(Type, 2). 

 canSafelyPush(Environment, InputOperandStack, Type, OutputOperandStack) :- pushOperandStack(InputOperandStack, Type, OutputOperandStack), operandStackHasLegalLength(Environment, OutputOperandStack). canSafelyPushList(Environment, InputOperandStack, Types, OutputOperandStack) :- canPushList(InputOperandStack, Types, OutputOperandStack), operandStackHasLegalLength(Environment, OutputOperandStack). canPushList(InputOperandStack, [], InputOperandStack). canPushList(InputOperandStack, [Type | Rest], OutputOperandStack) :- pushOperandStack(InputOperandStack, Type, InterimOperandStack), canPushList(InterimOperandStack, Rest, OutputOperandStack). 

 popCategory1([Type | Rest], Type, Rest) :- Type \= top, sizeOf(Type, 1). 

 popCategory2([top, Type | Rest], Type, Rest) :- sizeOf(Type, 2). 

 validTypeTransition(Environment, ExpectedTypesOnStack, ResultType, frame(Locals, InputOperandStack, Flags), frame(Locals, NextOperandStack, Flags)) :- popMatchingList(InputOperandStack, ExpectedTypesOnStack, InterimOperandStack), pushOperandStack(InterimOperandStack, ResultType, NextOperandStack), operandStackHasLegalLength(Environment, NextOperandStack). 

 methodIsTypeSafe(Class, Method) :- doesNotOverrideFinalMethod(Class, Method), methodAccessFlags(Method, AccessFlags), member(abstract, AccessFlags). methodIsTypeSafe(Class, Method) :- doesNotOverrideFinalMethod(Class, Method), methodAccessFlags(Method, AccessFlags), member(native, AccessFlags). doesNotOverrideFinalMethod(class('java/lang/Object', L), Method) :- isBootstrapLoader(L). doesNotOverrideFinalMethod(Class, Method) :- classSuperClassName(Class, SuperclassName), classDefiningLoader(Class, L), loadedClass(SuperclassName, L, Superclass), classMethods(Superclass, MethodList), finalMethodNotOverridden(Method, Superclass, MethodList). finalMethodNotOverridden(Method, Superclass, MethodList) :- methodName(Method, Name), methodDescriptor(Method, Descriptor), member(method(_, Name, Descriptor), MethodList), isNotFinal(Method, Superclass). finalMethodNotOverridden(Method, Superclass, MethodList) :- methodName(Method, Name), methodDescriptor(Method, Descriptor), notMember(method(_, Name, Descriptor), MethodList), doesNotOverrideFinalMethod(Superclass, Method). 

 methodIsTypeSafe(Class, Method) :- doesNotOverrideFinalMethod(Class, Method), methodAccessFlags(Method, AccessFlags), methodAttributes(Method, Attributes), notMember(native, AccessFlags), notMember(abstract, AccessFlags), member(attribute('Code', _), Attributes), methodWithCodeIsTypeSafe(Class, Method). 

 methodWithCodeIsTypeSafe(Class, Method) :- parseCodeAttribute(Class, Method, FrameSize, MaxStack, ParsedCode, Handlers, StackMap), mergeStackMapAndCode(StackMap, ParsedCode, MergedCode), methodInitialStackFrame(Class, Method, FrameSize, StackFrame, ReturnType), Environment = environment(Class, Method, ReturnType, MergedCode, MaxStack, Handlers), handlersAreLegal(Environment), mergedCodeIsTypeSafe(Environment, MergedCode, StackFrame). 

 handler(Start, End, Target, ClassName) 

 handlersAreLegal(Environment) :- exceptionHandlers(Environment, Handlers), checklist(handlerIsLegal(Environment), Handlers). handlerIsLegal(Environment, Handler) :- Handler = handler(Start, End, Target, _), Start < End, allInstructions(Environment, Instructions), member(instruction(Start, _), Instructions), offsetStackFrame(Environment, Target, _), instructionsIncludeEnd(Instructions, End), currentClassLoader(Environment, CurrentLoader), handlerExceptionClass(Handler, ExceptionClass, CurrentLoader), isBootstrapLoader(BL), isAssignable(ExceptionClass, class('java/lang/Throwable', BL)). instructionsIncludeEnd(Instructions, End) :- member(instruction(End, _), Instructions). instructionsIncludeEnd(Instructions, End) :- member(endOfCode(End), Instructions). handlerExceptionClass(handler(_, _, _, 0), class('java/lang/Throwable', BL), _) :- isBootstrapLoader(BL). handlerExceptionClass(handler(_, _, _, Name), class(Name, L), L) :- Name \= 0. 

 methodInitialStackFrame(Class, Method, FrameSize, frame(Locals, [], Flags), ReturnType):- methodDescriptor(Method, Descriptor), parseMethodDescriptor(Descriptor, RawArgs, ReturnType), expandTypeList(RawArgs, Args), methodInitialThisType(Class, Method, ThisList), flags(ThisList, Flags), append(ThisList, Args, ThisArgs), expandToLength(ThisArgs, FrameSize, top, Locals). 

 expandTypeList([], []). expandTypeList([Item | List], [Item | Result]) :- sizeOf(Item, 1), expandTypeList(List, Result). expandTypeList([Item | List], [Item, top | Result]) :- sizeOf(Item, 2), expandTypeList(List, Result). 

 flags([uninitializedThis], [flagThisUninit]). flags(X, []) :- X \= [uninitializedThis]. expandToLength(List, Size, _Filler, List) :- length(List, Size). expandToLength(List, Size, Filler, Result) :- length(List, ListLength), ListLength < Size, Delta is Size - ListLength, length(Extra, Delta), checklist(=(Filler), Extra), append(List, Extra, Result). 

 methodInitialThisType(_Class, Method, []) :- methodAccessFlags(Method, AccessFlags), member(static, AccessFlags), methodName(Method, MethodName), MethodName \= '<init>'. methodInitialThisType(Class, Method, [This]) :- methodAccessFlags(Method, AccessFlags),\ notMember(static, AccessFlags),\ instanceMethodInitialThisType(Class, Method, This). instanceMethodInitialThisType(Class, Method, class('java/lang/Object', L)) :- methodName(Method, '<init>'), classDefiningLoader(Class, L), isBootstrapLoader(L), classClassName(Class, 'java/lang/Object'). instanceMethodInitialThisType(Class, Method, uninitializedThis) :- methodName(Method, '<init>'), classClassName(Class, ClassName), classDefiningLoader(Class, CurrentLoader), superclassChain(ClassName, CurrentLoader, Chain), Chain \= []. instanceMethodInitialThisType(Class, Method, class(ClassName, L)) :- methodName(Method, MethodName), MethodName \= '<init>', classDefiningLoader(Class, L), classClassName(Class, ClassName).