This chapter describes the
class file format of the Java Virtual Machine. Each class file contains the
definition of a single class or interface. Although a class or
interface need not have an external representation literally contained
in a file (for instance, because the class is generated by a class
loader), we will colloquially refer to any valid representation of a
class or interface as being in the class file format.

A class file consists of a
stream of 8-bit bytes. All 16-bit, 32-bit, and 64-bit quantities are
constructed by reading in two, four, and eight consecutive 8-bit
bytes, respectively. Multibyte data items are always stored in
big-endian order, where the high bytes come first. In the Java SE platform,
this format is supported by
interfaces java.io.DataInput
and java.io.DataOutput and classes such as
java.io.DataInputStream
and java.io.DataOutputStream.

This chapter defines its own set
of data types representing class file data: The
types u1, u2,
and u4 represent an unsigned one-, two-, or
four-byte quantity, respectively. In the Java SE platform, these types may
be read by methods such as readUnsignedByte,
readUnsignedShort, and readInt
of the interface java.io.DataInput.

This chapter presents the
class file format using pseudostructures written in a C-like
structure notation. To avoid confusion with the fields of classes and
class instances, etc., the contents of the structures describing the
class file format are referred to as items.
Successive items are stored in the class file sequentially, without
padding or alignment.

Tables,
consisting of zero or more variable-sized items, are used in several
class file structures. Although we use C-like array syntax to refer
to table items, the fact that tables are streams of varying-sized
structures means that it is not possible to translate a table index
directly to a byte offset into the table.

Where we refer to a data
structure as an array, it consists of zero or
more contiguous fixed-sized items and can be indexed like an
array.

Reference to an ASCII character
in this chapter should be interpreted to mean the Unicode code point
corresponding to the ASCII character.

The magic item supplies the magic number
identifying the class file format; it has the
value 0xCAFEBABE.

minor_version, major_version

The values of the minor_version
and major_version items are the minor and
major version numbers of this class file. Together, a major
and a minor version number determine the version of the
class file format. If a class file has major version
number M and minor version number m, we denote the version of
its class file format as M.m. Thus, class file format
versions may be ordered lexicographically, for example, 1.5
< 2.0 < 2.1.

A Java Virtual Machine implementation can support a class file format of
version v if and only if v lies in some contiguous range Mi.0
≤ v ≤ Mj.m. The release level of the Java SE platform to
which a Java Virtual Machine implementation conforms is responsible for
determining the range.

The value of the constant_pool_count item
is equal to the number of entries in the constant_pool table
plus one. A constant_pool index is considered valid if it is
greater than zero and less
than constant_pool_count, with the
exception for constants of type long and double noted in
§4.4.5.

constant_pool[]

The constant_pool is a table of structures
(§4.4) representing various string
constants, class and interface names, field names, and other
constants that are referred to within the ClassFile
structure and its substructures. The format of each
constant_pool table entry is indicated by its first "tag"
byte.

The constant_pool table is indexed from 1
to constant_pool_count - 1.

access_flags

The value of the access_flags item is a mask of flags used
to denote access permissions to and properties of this class
or interface. The interpretation of each flag, when set, is
specified in Table 4.1-A.

Table 4.1-A. Class access and property modifiers

Flag Name

Value

Interpretation

ACC_PUBLIC

0x0001

Declared public; may be accessed from outside its
package.

ACC_FINAL

0x0010

Declared final; no subclasses allowed.

ACC_SUPER

0x0020

Treat superclass methods specially when invoked
by the invokespecial instruction.

ACC_INTERFACE

0x0200

Is an interface, not a class.

ACC_ABSTRACT

0x0400

Declared abstract; must not be
instantiated.

ACC_SYNTHETIC

0x1000

Declared synthetic; not present in the source
code.

ACC_ANNOTATION

0x2000

Declared as an annotation type.

ACC_ENUM

0x4000

Declared as an enum type.

An interface is distinguished by the ACC_INTERFACE flag
being set. If the ACC_INTERFACE flag is not set, this
class file defines a class, not an interface.

If the ACC_INTERFACE flag is set, the ACC_ABSTRACT flag
must also be set, and the ACC_FINAL, ACC_SUPER, and
ACC_ENUM flags set must not be set.

If the ACC_INTERFACE flag is not set, any of the other flags
in Table 4.1-A may be set except
ACC_ANNOTATION. However, such a class file must not have
both its ACC_FINAL and ACC_ABSTRACT flags set (JLS
§8.1.1.2).

The ACC_SUPER flag indicates which of two alternative
semantics is to be expressed by the invokespecial
instruction (§invokespecial) if it
appears in this class or interface. Compilers to the
instruction set of the Java Virtual Machine should set the ACC_SUPER
flag. In Java SE 8 and above, the Java Virtual Machine considers the
ACC_SUPER flag to be set in every class file, regardless
of the actual value of the flag in the class file and the
version of the class file.

The ACC_SUPER flag exists for backward
compatibility with code compiled by older compilers for the
Java programming language. In JDK releases prior to 1.0.2, the compiler
generated access_flags in which the flag now representing
ACC_SUPER had no assigned meaning, and Oracle's Java Virtual Machine
implementation ignored the flag if it was set.

The ACC_SYNTHETIC flag indicates that this class or
interface was generated by a compiler and does not appear in
source code.

An annotation type must have its ACC_ANNOTATION flag set. If
the ACC_ANNOTATION flag is set, the ACC_INTERFACE flag
must also be set.

The ACC_ENUM flag indicates that this class or its
superclass is declared as an enumerated type.

All bits of the access_flags item not assigned in
Table 4.1-A are reserved for future
use. They should be set to zero in generated class files and
should be ignored by Java Virtual Machine implementations.

this_class

The value of the this_class item must be a
valid index into the constant_pool table. The
constant_pool entry at that index must be a
CONSTANT_Class_info structure (§4.4.1)
representing the class or interface defined by this class
file.

super_class

For a class, the value of the super_class
item either must be zero or must be a valid index into the
constant_pool table. If the value of
the super_class item is nonzero, the
constant_pool entry at that index must be a
CONSTANT_Class_info structure representing the direct
superclass of the class defined by this class file. Neither
the direct superclass nor any of its superclasses may have the
ACC_FINAL flag set in the access_flags item of its
ClassFile structure.

If the value of the super_class item is
zero, then this class file must represent the class
Object, the only class or interface without a direct
superclass.

For an interface, the value of the
super_class item must always be a valid
index into the constant_pool table. The constant_pool
entry at that index must be a CONSTANT_Class_info structure
representing the class Object.

interfaces_count

The value of the interfaces_count item
gives the number of direct superinterfaces of this class or
interface type.

interfaces[]

Each value in the interfaces array must be
a valid index into the constant_pool table. The
constant_pool entry at each value of
interfaces[i], where 0 ≤i
< interfaces_count, must be a
CONSTANT_Class_info structure representing an interface that
is a direct superinterface of this class or interface type, in
the left-to-right order given in the source for the
type.

fields_count

The value of the fields_count item gives
the number of field_info structures in
the fields table. The field_info
structures represent all fields, both class variables and
instance variables, declared by this class or interface
type.

fields[]

Each value in the fields table must be a
field_info structure (§4.5) giving a
complete description of a field in this class or
interface. The fields table includes only
those fields that are declared by this class or interface. It
does not include items representing fields that are inherited
from superclasses or superinterfaces.

methods_count

The value of the methods_count item gives
the number of method_info structures in
the methods table.

methods[]

Each value in the methods table must be a
method_info structure (§4.6) giving a
complete description of a method in this class or
interface. If neither of the ACC_NATIVE and ACC_ABSTRACT
flags are set in the access_flags item of a method_info
structure, the Java Virtual Machine instructions implementing the method are
also supplied.

The method_info structures represent all methods declared by
this class or interface type, including instance methods,
class methods, instance initialization methods
(§2.9), and any class or interface
initialization method (§2.9). The
methods table does not include items
representing methods that are inherited from superclasses or
superinterfaces.

attributes_count

The value of the attributes_count item
gives the number of attributes in the attributes table of
this class.

attributes[]

Each value of the attributes table must be an
attribute_info structure
(§4.7).

The attributes defined by this specification as appearing in
the attributes table of a ClassFile structure are listed
in Table 4.7-C.

The rules concerning attributes defined to appear in the
attributes table of a ClassFile structure are given in
§4.7.

The rules concerning non-predefined attributes in the
attributes table of a ClassFile structure are given in
§4.7.1.

4.2. The Internal Form of Names

4.2.1. Binary Class and Interface Names

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.

4.2.2. Unqualified Names

Names of methods, fields, local
variables, and formal parameters are stored as unqualified
names. An unqualified name must contain at least one
Unicode code point and 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>.

4.3. Descriptors

A descriptor is a string
representing the type of a field or method. Descriptors are
represented in the class file format using modified UTF-8 strings
(§4.4.7) and thus may be drawn, where not
further constrained, from the entire Unicode codespace.

4.3.1. Grammar Notation

Descriptors are specified
using a grammar. The grammar is a set of productions that describe how
sequences of characters can form syntactically correct descriptors of
various kinds. Terminal symbols of the grammar are shown
in 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 definitions for the nonterminal
then follow on succeeding lines.

The syntax
{x} on the right-hand side of a production
denotes zero or more occurrences of x.

The phrase (one
of) on the right-hand side of a production signifies that
each of the terminal symbols on the following line or lines is an
alternative definition.

4.3.2. Field Descriptors

A field
descriptor represents the type of a class, instance, or
local variable.

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

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

The interpretation of field
descriptors as types is shown in Table 4.3-A.

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

Table 4.3-A. Interpretation of field descriptors

FieldType term

Type

Interpretation

B

byte

signed byte

C

char

Unicode character code point in the Basic Multilingual
Plane, encoded with UTF-16

D

double

double-precision floating-point value

F

float

single-precision floating-point value

I

int

integer

J

long

long integer

LClassName;

reference

an instance of class ClassName

S

short

signed short

Z

boolean

true or false

[

reference

one array dimension

The field descriptor of an instance variable of type
int is simply I.

The field descriptor of an instance variable of type
Object is Ljava/lang/Object;. Note that the
internal form of the binary name for class Object is used.

The field descriptor of an instance variable of the
multidimensional array type double[][][]
is [[[D.

4.3.3. Method Descriptors

A method
descriptor contains zero or more parameter
descriptors, representing the types of parameters that the
method takes, and a return descriptor,
representing the type of the value (if any) that the method
returns.

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

The method descriptor for the method:

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

is:

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

Note that the internal forms of the binary names of
Thread and Object are used.

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.

A method
descriptor is the same whether the method it describes is a class
method or an instance method. Although an instance method is passed
this, a reference to the object on which the method is being
invoked, in addition to its intended arguments, that fact is not
reflected in the method descriptor. The reference to this is passed
implicitly by the Java Virtual Machine instructions which invoke instance methods
(§2.6.1, §4.11).

4.4. The Constant Pool

Java Virtual Machine instructions do not rely
on the run-time layout of classes, interfaces, class instances, or
arrays. Instead, instructions refer to symbolic information in the
constant_pool table.

All constant_pool table
entries have the following general format:

cp_info {
u1 tag;
u1 info[];
}

Each item in the
constant_pool table must begin with a 1-byte tag indicating the kind
of cp_info entry. The contents of
the info array vary with the value
of tag. The valid tags and their values are listed
in Table 4.4-A. Each tag byte must be followed by
two or more bytes giving information about the specific constant. The
format of the additional information varies with the tag value.

Table 4.4-A. Constant pool tags

Constant Type

Value

CONSTANT_Class

7

CONSTANT_Fieldref

9

CONSTANT_Methodref

10

CONSTANT_InterfaceMethodref

11

CONSTANT_String

8

CONSTANT_Integer

3

CONSTANT_Float

4

CONSTANT_Long

5

CONSTANT_Double

6

CONSTANT_NameAndType

12

CONSTANT_Utf8

1

CONSTANT_MethodHandle

15

CONSTANT_MethodType

16

CONSTANT_InvokeDynamic

18

4.4.1. The CONSTANT_Class_info Structure

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 as follows:

tag

The tag item has
the value CONSTANT_Class (7).

name_index

The value of the
name_index item must be a valid index into
the constant_pool table. The constant_pool entry at that
index must be a CONSTANT_Utf8_info structure
(§4.4.7) representing a valid binary class
or interface name encoded in internal form
(§4.2.1).

Because arrays are objects,
the opcodes anewarray and multianewarray - but not the opcode
new - 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
(§4.3.2).

For example, the class name representing the
two-dimensional array type int[][]
is [[I, while the class name representing the
type Thread[]
is [Ljava/lang/Thread;.

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

The tag item of
a CONSTANT_Fieldref_info structure has the
value CONSTANT_Fieldref (9).

The tag item of
a CONSTANT_Methodref_info structure has the
value CONSTANT_Methodref (10).

The tag item of
a CONSTANT_InterfaceMethodref_info structure has the value
CONSTANT_InterfaceMethodref (11).

class_index

The value of the class_index item must be a
valid index into the constant_pool table. The
constant_pool entry at that index must be a
CONSTANT_Class_info structure (§4.4.1)
representing a class or interface type that has the field or
method as a member.

The class_index item of a
CONSTANT_Methodref_info structure must be a class type, not
an interface type.

The class_index item of a
CONSTANT_InterfaceMethodref_info structure must be an
interface type.

The class_index item of a
CONSTANT_Fieldref_info structure may be either a class type
or an interface type.

name_and_type_index

The value of the name_and_type_index item
must be a valid index into the constant_pool table. The
constant_pool entry at that index must be a
CONSTANT_NameAndType_info structure
(§4.4.6). This constant_pool entry
indicates the name and descriptor of the field or
method.

In a CONSTANT_Fieldref_info, the indicated descriptor must
be a field descriptor
(§4.3.2). Otherwise, the indicated
descriptor must be a method descriptor
(§4.3.3).

If the name of the method of a CONSTANT_Methodref_info
structure begins with a '<'
('\u003c'), then the name must be the
special name <init>, representing an instance initialization
method (§2.9). The return type of such a
method must be void.

4.4.3. The CONSTANT_String_info Structure

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:

tag

The tag item of
the CONSTANT_String_info structure has the value
CONSTANT_String (8).

string_index

The value of
the string_index item must be a valid index
into the constant_pool table. The constant_pool entry at
that index must be a CONSTANT_Utf8_info structure
(§4.4.7) representing the sequence of
Unicode code points to which the String object is to be
initialized.

The tag item of
the CONSTANT_Integer_info structure has the value
CONSTANT_Integer (3).

The tag item of
the CONSTANT_Float_info structure has the value
CONSTANT_Float (4).

bytes

The bytes item of
the CONSTANT_Integer_info structure represents the value of
the int constant. The bytes of the value are stored in
big-endian (high byte first) order.

The bytes item of
the CONSTANT_Float_info structure represents the value of the
float constant in IEEE 754 floating-point single format
(§2.3.2). The bytes of the single format
representation are stored in big-endian (high byte first)
order.

The value
represented by the CONSTANT_Float_info structure is determined
as follows. The bytes of the value are first converted into an
int constant bits. Then:

If bits
is 0x7f800000, the float value will be
positive infinity.

If bits
is 0xff800000, the float value will be
negative infinity.

If bits
is in the range 0x7f800001 through
0x7fffffff or in the
range 0xff800001
through 0xffffffff, the float value
will be NaN.

In all other
cases, let s, e,
and m be three values that might be
computed from bits:

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:

tag

The tag item of
the CONSTANT_Long_info structure has the value CONSTANT_Long
(5).

The tag item of
the CONSTANT_Double_info structure has the value
CONSTANT_Double (6).

high_bytes, low_bytes

The
unsigned high_bytes
and low_bytes items of the
CONSTANT_Long_info structure together represent the value of
the long constant

((long) high_bytes << 32) + low_bytes

where the bytes of
each of high_bytes
and low_bytes are stored in big-endian (high
byte first) order.

The high_bytes
and low_bytes items of the
CONSTANT_Double_info structure together represent the double
value in IEEE 754 floating-point double format
(§2.3.2). The bytes of each item are
stored in big-endian (high byte first) order.

The value
represented by the CONSTANT_Double_info structure is
determined as follows. The high_bytes
and low_bytes items are converted into the
long constant bits, which is equal
to

((long) high_bytes << 32) + low_bytes

Then:

If bits
is 0x7ff0000000000000L, the double
value will be positive infinity.

If bits
is 0xfff0000000000000L, the double
value will be negative infinity.

If bits
is in the range 0x7ff0000000000001L through
0x7fffffffffffffffL or in the
range 0xfff0000000000001L
through 0xffffffffffffffffL, the double
value will be NaN.

In all other
cases, let s, e,
and m be three values that might be
computed from bits:

The tag item of
the CONSTANT_NameAndType_info structure has the value
CONSTANT_NameAndType (12).

name_index

The value of
the name_index item must be a valid index
into the constant_pool table. The constant_pool entry at
that index must be a CONSTANT_Utf8_info structure
(§4.4.7) representing either the special
method name <init> (§2.9) or a valid
unqualified name denoting a field or method
(§4.2.2).

descriptor_index

The value of
the descriptor_index item must be a valid
index into the constant_pool table. The constant_pool entry
at that index must be a CONSTANT_Utf8_info structure
(§4.4.7) representing a valid field
descriptor or method descriptor (§4.3.2,
§4.3.3).

4.4.7. The CONSTANT_Utf8_info Structure

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 as follows:

tag

The tag item of the CONSTANT_Utf8_info structure has the
value CONSTANT_Utf8 (1).

length

The value of the length item gives the
number of bytes in the bytes array (not the
length of the resulting string).

bytes[]

The bytes array contains the bytes of the
string.

No byte may have the value (byte)0.

No byte may lie in the range (byte)0xf0
to (byte)0xff.

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. Modified UTF-8 strings are
not null-terminated. The encoding is as follows:

Code points in the range '\u0001' to
'\u007F' are represented by a single
byte:

Table 4.4.

0

bits 6-0

The 7 bits of data in the byte give the value of the code point
represented.

The null code point ('\u0000') and code
points in the range '\u0080' to
'\u07FF' are represented by a pair of
bytes x and y :

Table 4.5.

x:

Table 4.6.

1

1

0

bits 10-6

y:

Table 4.7.

1

0

bits 5-0

The two bytes represent the code point with the value:

((x & 0x1f) << 6) + (y & 0x3f)

Code points in the range '\u0800' to
'\uFFFF' are represented by 3
bytes x, y,
and z :

Table 4.8.

x:

Table 4.9.

1

1

1

0

bits 15-12

y:

Table 4.10.

1

0

bits 11-6

z:

Table 4.11.

1

0

bits 5-0

The three bytes represent the code point with the value:

((x & 0xf) << 12) + ((y & 0x3f) << 6) + (z & 0x3f)

Characters with code points above U+FFFF
(so-called supplementary characters) are
represented by separately encoding the two surrogate code units
of their UTF-16 representation. Each of the surrogate code units
is represented by three bytes. This means supplementary
characters are represented by six
bytes, u, v, w, x,
y, and z :

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.

4.4.8. The CONSTANT_MethodHandle_info Structure

The
CONSTANT_MethodHandle_info structure is used to represent a method
handle:

The items of the
CONSTANT_MethodHandle_info structure are the following:

tag

The tag item of the CONSTANT_MethodHandle_info structure
has the value CONSTANT_MethodHandle (15).

reference_kind

The value of the reference_kind item must
be in the range 1 to 9. The value denotes
the kind of this method handle, which
characterizes its bytecode behavior
(§5.4.3.5).

reference_index

The value of the reference_index item must
be a valid index into the constant_pool table. The
constant_pool entry at that index must be as follows:

If the value of the reference_kind item
is 1 (REF_getField), 2 (REF_getStatic), 3
(REF_putField), or 4 (REF_putStatic), then the
constant_pool entry at that index must be a
CONSTANT_Fieldref_info (§4.4.2)
structure representing a field for which a method handle
is to be created.

If the value of the reference_kind item
is 5 (REF_invokeVirtual) or 8 (REF_newInvokeSpecial),
then the constant_pool entry at that index must be a
CONSTANT_Methodref_info structure
(§4.4.2) representing a class's
method or constructor (§2.9) for
which a method handle is to be created.

If the value of the reference_kind item
is 6 (REF_invokeStatic) or 7 (REF_invokeSpecial), then
if the class file version number is less than 52.0, the
constant_pool entry at that index must be a
CONSTANT_Methodref_info structure representing a class's
method for which a method handle is to be created; if the
class file version number is 52.0 or above, the
constant_pool entry at that index must be either a
CONSTANT_Methodref_info structure or a
CONSTANT_InterfaceMethodref_info structure
(§4.4.2) representing a class's or
interface's method for which a method handle is to be
created.

If the value of the reference_kind item
is 9 (REF_invokeInterface), then the constant_pool
entry at that index must be a
CONSTANT_InterfaceMethodref_info structure representing
an interface's method for which a method handle is to be
created.

If the value of the reference_kind item is
5 (REF_invokeVirtual), 6 (REF_invokeStatic), 7
(REF_invokeSpecial), or 9 (REF_invokeInterface), the name
of the method represented by a CONSTANT_Methodref_info
structure or a CONSTANT_InterfaceMethodref_info structure
must not be <init> or <clinit>.

If the value is 8 (REF_newInvokeSpecial), the name of the
method represented by a CONSTANT_Methodref_info structure
must be <init>.

4.4.9. The CONSTANT_MethodType_info Structure

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:

tag

The tag item of
the CONSTANT_MethodType_info structure has the value
CONSTANT_MethodType (16).

descriptor_index

The value of
the descriptor_index item must be a valid
index into the constant_pool table. The constant_pool entry
at that index must be a CONSTANT_Utf8_info structure
(§4.4.7) representing a method descriptor
(§4.3.3).

4.4.10. The CONSTANT_InvokeDynamic_info Structure

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.

The items of the
CONSTANT_InvokeDynamic_info structure are as follows:

tag

The tag item of
the CONSTANT_InvokeDynamic_info structure has the value
CONSTANT_InvokeDynamic (18).

bootstrap_method_attr_index

The value of the
bootstrap_method_attr_index item must be a
valid index into the bootstrap_methods array
of the bootstrap method table (§4.7.23) of
this class file.

name_and_type_index

The value of the name_and_type_index item
must be a valid index into the constant_pool table. The
constant_pool entry at that index must be a
CONSTANT_NameAndType_info structure
(§4.4.6) representing a method name and
method descriptor (§4.3.3).

4.5. Fields

Each field is described by a
field_info structure.

No two fields in one class
file may have the same name and descriptor
(§4.3.2).

Declared transient; not written or read by a
persistent object manager.

ACC_SYNTHETIC

0x1000

Declared synthetic; not present in the source
code.

ACC_ENUM

0x4000

Declared as an element of an enum.

Fields of classes may set any of the flags in
Table 4.5-A. However, each field of a
class may have at most one of its ACC_PUBLIC, ACC_PRIVATE,
and ACC_PROTECTED flags set (JLS §8.3.1), and must not have
both its ACC_FINAL and ACC_VOLATILE flags set (JLS
§8.3.1.4).

Fields of interfaces must have their ACC_PUBLIC,
ACC_STATIC, and ACC_FINAL flags set; they may have their
ACC_SYNTHETIC flag set and must not have any of the other
flags in Table 4.5-A set (JLS
§9.3).

The ACC_SYNTHETIC flag indicates that this field was
generated by a compiler and does not appear in source
code.

The ACC_ENUM flag indicates that this field is used to hold
an element of an enumerated type.

All bits of the access_flags item not assigned in
Table 4.5-A are reserved for future
use. They should be set to zero in generated class files and
should be ignored by Java Virtual Machine implementations.

name_index

The value of the
name_index item must be a valid index into
the constant_pool table. The constant_pool entry at that
index must be a CONSTANT_Utf8_info structure
(§4.4.7) which represents a valid
unqualified name denoting a field
(§4.2.2).

descriptor_index

The value of the
descriptor_index item must be a valid index
into the constant_pool table. The constant_pool entry at
that index must be a CONSTANT_Utf8_info structure
(§4.4.7) which represents a valid field
descriptor (§4.3.2).

attributes_count

The value of the
attributes_count item indicates the number of
additional attributes of this field.

attributes[]

Each value of the
attributes table must be an attribute_info structure
(§4.7).

A field can have any number of optional attributes associated
with it.

The attributes defined by this specification as appearing in
the attributes table of a field_info structure are listed
in Table 4.7-C.

The rules concerning attributes defined to appear in the
attributes table of a field_info structure are given in
§4.7.

The rules concerning non-predefined attributes in the
attributes table of a field_info structure are given in
§4.7.1.

4.6. Methods

Each method, including each
instance initialization method (§2.9) and the
class or interface initialization method (§2.9),
is described by a method_info structure.

No two methods in one class
file may have the same name and descriptor
(§4.3.3).

Methods of classes may have any of the flags in
Table 4.6-A set. However, each method
of a class may have at most one of its ACC_PUBLIC,
ACC_PRIVATE, and ACC_PROTECTED flags set (JLS
§8.4.3).

Methods of interfaces may have any of the flags in
Table 4.6-A set except ACC_PROTECTED,
ACC_FINAL, ACC_SYNCHRONIZED, and ACC_NATIVE (JLS
§9.4). In a class file whose version number is less than
52.0, each method of an interface must have its ACC_PUBLIC
and ACC_ABSTRACT flags set; in a class file whose version
number is 52.0 or above, each method of an interface must have
exactly one of its ACC_PUBLIC and ACC_PRIVATE flags
set.

If a method of a class or interface has its ACC_ABSTRACT
flag set, it must not have any of its ACC_PRIVATE,
ACC_STATIC, ACC_FINAL, ACC_SYNCHRONIZED, ACC_NATIVE, or
ACC_STRICT flags set.

Each instance initialization method
(§2.9) may have at most one of its
ACC_PUBLIC, ACC_PRIVATE, and ACC_PROTECTED flags set,
and may also have its ACC_VARARGS, ACC_STRICT, and
ACC_SYNTHETIC flags set, but must not have any of the other
flags in Table 4.6-A set.

Class and interface initialization methods are called
implicitly by the Java Virtual Machine. The value of their access_flags
item is ignored except for the setting of the ACC_STRICT
flag.

The ACC_BRIDGE flag is used to indicate a bridge method
generated by a compiler for the Java programming language.

The ACC_VARARGS flag indicates that this method takes a
variable number of arguments at the source code level. A
method declared to take a variable number of arguments must be
compiled with the ACC_VARARGS flag set to 1. All other
methods must be compiled with the ACC_VARARGS flag set to
0.

The ACC_SYNTHETIC flag indicates that this method was
generated by a compiler and does not appear in source code,
unless it is one of the methods named in
§4.7.8.

All bits of the access_flags item not assigned in
Table 4.6-A are reserved for future
use. They should be set to zero in generated class files and
should be ignored by Java Virtual Machine implementations.

name_index

The value of the
name_index item must be a valid index into
the constant_pool table. The constant_pool entry at that
index must be a CONSTANT_Utf8_info structure
(§4.4.7) representing either one of the
special method names <init> or <clinit>
(§2.9), or a valid unqualified name
denoting a method (§4.2.2).

descriptor_index

The value of the
descriptor_index item must be a valid index
into the constant_pool table. The constant_pool entry at
that index must be a CONSTANT_Utf8_info structure representing
a valid method descriptor (§4.3.3).

A future edition of this specification may
require that the last parameter descriptor of the method
descriptor is an array type if the ACC_VARARGS flag is set in
the access_flags item.

attributes_count

The value of the
attributes_count item indicates the number of
additional attributes of this method.

attributes[]

Each value of the
attributes table must be an attribute_info structure
(§4.7).

A method can have
any number of optional attributes associated with it.

The attributes defined by this specification as appearing in
the attributes table of a method_info structure are listed
in Table 4.7-C.

The rules concerning attributes defined to appear in the
attributes table of a method_info structure are given in
§4.7.

The rules concerning non-predefined attributes in the
attributes table of a method_info structure are given in
§4.7.1.

4.7. Attributes

Attributes
are used in the ClassFile, field_info, method_info, and
Code_attribute structures of the class file format
(§4.1, §4.5,
§4.6, §4.7.3).

For all attributes, the
attribute_name_index must be a valid unsigned
16-bit index into the constant pool of the class. The constant_pool
entry at attribute_name_index must be a
CONSTANT_Utf8_info structure (§4.4.7)
representing the name of the attribute. The value of the
attribute_length item indicates the length of the
subsequent information in bytes. The length does not include the
initial six bytes that contain
the attribute_name_index
and attribute_length items.

23 attributes are predefined by this
specification. They are listed three times, for ease of
navigation:

Table 4.7-A is ordered by the attributes'
section numbers in this chapter. Each attribute is accompanied
by the first version of the class file format in which it was
defined, and the corresponding version of the Java SE platform. (For
old class file versions, the JDK release is used instead of
the Java SE platform version).

Table 4.7-B is orderd by the first version of
the class file format in which each attribute was
defined.

Table 4.7-C is ordered by the location in a
class file where each attribute is defined to appear.

Within the context of their
use in this specification, that is, in the attributes tables of the
class file structures in which they appear, the names of these
predefined attributes are reserved.

Any conditions on the presence of a
predefined attribute in an attributes table are specified explicitly
in the section which describes the attribute. If no conditions are
specified, then the attribute may appear any number of times in an
attributes table.

The predefined attributes
are categorized into three groups according to their purpose:

Five attributes are critical to correct interpretation of the
class file by the Java Virtual Machine:

ConstantValue

Code

StackMapTable

Exceptions

BootstrapMethods

In a class file of version V, each of these attributes must
be recognized and correctly read by an implementation of the
Java Virtual Machine if the implementation recognizes class files of version
V, and V is at least the version where the attribute was
first defined, and the attribute appears in a location where it
is defined to appear.

Twelve attributes are critical to correct interpretation of the
class file by the class libraries of the Java SE platform:

InnerClasses

EnclosingMethod

Synthetic

Signature

RuntimeVisibleAnnotations

RuntimeInvisibleAnnotations

RuntimeVisibleParameterAnnotations

RuntimeInvisibleParameterAnnotations

RuntimeVisibleTypeAnnotations

RuntimeInvisibleTypeAnnotations

AnnotationDefault

MethodParameters

Each of these attributes in a class file of version V must
be recognized and correctly read by an implementation of the
class libraries of the Java SE platform if the implementation
recognizes class files of version V, and V is at least the
version where the attribute was first defined, and the attribute
appears in a location where it is defined to appear.

Six attributes are not critical to correct interpretation of the
class file by either the Java Virtual Machine or the class libraries of the
Java SE platform, but are useful for tools:

SourceFile

SourceDebugExtension

LineNumberTable

LocalVariableTable

LocalVariableTypeTable

Deprecated

Use of these attributes by an implementation of the Java Virtual Machine or the
class libraries of the Java SE platform is optional. An implementation
may use the information that these attributes contain, or
otherwise must silently ignore these attributes.

4.7.1. Defining and Naming New Attributes

Compilers are permitted to define
and emit class files containing new attributes in the attributes
tables of class file structures, field_info structures,
method_info structures, and Code attributes
(§4.7.3). Java Virtual Machine implementations are permitted to
recognize and use new attributes found in these attributes
tables. However, any attribute not defined as part of the class file
specification must not affect the semantics of the class file. 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 8 Edition (JLS §6.1).

Future versions of this
specification may define additional attributes.

4.7.2. The ConstantValue Attribute

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 expression
(JLS §15.28), and is used as follows:

If the ACC_STATIC
flag in the access_flags item of the field_info structure is
set, then the field represented by the
field_info structure is assigned the value represented by its
ConstantValue attribute as part of the initialization of the
class or interface declaring the field
(§5.5). This occurs prior to the
invocation of the class or interface initialization method of
that class or interface (§2.9).

Otherwise, the Java Virtual Machine
must silently ignore the attribute.

There may be at most one
ConstantValue attribute in the attributes table of a field_info
structure.

The value of the
attribute_name_index item must be a valid
index into the constant_pool table. The constant_pool entry
at that index must be a CONSTANT_Utf8_info structure
(§4.4.7) representing the string
"ConstantValue".

attribute_length

The value of
the attribute_length item of a
ConstantValue_attribute structure must be
two.

constantvalue_index

The value of the
constantvalue_index item must be a valid
index into the constant_pool table. The constant_pool entry
at that index gives the constant value represented by this
attribute. The constant_pool entry must be of a type
appropriate to the field, as specified in
Table 4.7.2-A.

Table 4.7.2-A. Constant value attribute types

Field Type

Entry Type

long

CONSTANT_Long

float

CONSTANT_Float

double

CONSTANT_Double

int, short, char, byte, boolean

CONSTANT_Integer

String

CONSTANT_String

4.7.3. The Code Attribute

The Code attribute is a
variable-length attribute in the attributes table of a method_info
structure (§4.6). A Code attribute contains
the Java Virtual Machine instructions and auxiliary information for a method,
including an instance initialization method or a class or interface
initialization method (§2.9).

If the method is either
native or abstract, its method_info structure must not have a
Code attribute in its attributes table. Otherwise, its
method_info structure must have exactly one Code attribute in its
attributes table.

The value of the
attribute_name_index item must be a valid
index into the constant_pool table. The constant_pool entry
at that index must be a CONSTANT_Utf8_info structure
(§4.4.7) representing the string
"Code".

attribute_length

The value of the
attribute_length item indicates the length of
the attribute, excluding the initial six bytes.

max_stack

The value of the
max_stack item gives the maximum depth of the
operand stack of this method (§2.6.2) at
any point during execution of the method.

max_locals

The value of the
max_locals item gives the number of local
variables in the local variable array allocated upon invocation
of this method (§2.6.1), including the
local variables used to pass parameters to the method on its
invocation.

The greatest local
variable index for a value of type long or double is
max_locals - 2. The greatest local variable
index for a value of any other type is max_locals -
1.

code_length

The value of the
code_length item gives the number of bytes
in the code array for this method.

The
value of code_length must be greater than
zero (as the code array must not be empty) and less than
65536.

code[]

The code array
gives the actual bytes of Java Virtual Machine code that implement the
method.

When
the code array is read into memory on a
byte-addressable machine, if the first byte of the array is
aligned on a 4-byte boundary, the tableswitch and
lookupswitch 32-bit offsets will be 4-byte aligned. (Refer to
the descriptions of those instructions for more information on
the consequences of code array
alignment.)

The detailed
constraints on the contents of the code array
are extensive and are given in a separate section
(§4.9).

exception_table_length

The value of the
exception_table_length item gives the number
of entries in the exception_table
table.

exception_table[]

Each entry in the
exception_table array describes one exception
handler in the code array. The order of the handlers in
the exception_table array is significant
(§2.10).

Each
exception_table entry contains the following
four items:

start_pc, end_pc

The values
of the two items start_pc
and end_pc indicate the ranges in the
code array at which the exception handler is active. The
value of start_pc must be a valid index
into the code array of the opcode of an instruction. The
value of end_pc either must be a valid
index into the code array of the opcode of an
instruction or must be equal
to code_length, the length of the
code array. The value of start_pc
must be less than the value
of end_pc.

The
start_pc is inclusive
and end_pc is exclusive; that is, the
exception handler must be active while the program counter
is within the interval
[start_pc, end_pc).

The fact that end_pc
is exclusive is a historical mistake in the design of the
Java Virtual Machine: if the Java Virtual Machine code for a method is exactly 65535
bytes long and ends with an instruction that is 1 byte
long, then that instruction cannot be protected by an
exception handler. A compiler writer can work around this
bug by limiting the maximum size of the generated Java Virtual Machine
code for any method, instance initialization method, or
static initializer (the size of any code array) to 65534
bytes.

handler_pc

The value
of the handler_pc item indicates the
start of the exception handler. The value of the item must
be a valid index into the code array and must be the
index of the opcode of an instruction.

catch_type

If the
value of the catch_type item is
nonzero, it must be a valid index into the
constant_pool table. The constant_pool entry at that
index must be a CONSTANT_Class_info structure
(§4.4.1) representing a class of
exceptions that this exception handler is designated to
catch. The exception handler will be called only if the
thrown exception is an instance of the given class or
one of its subclasses.

The verifier checks that the class is
Throwable or a subclass of Throwable
(§4.9.2).

If the
value of the catch_type item is zero,
this exception handler is called for all
exceptions.

The value of the
attributes_count item indicates the number of
attributes of the Code attribute.

attributes[]

Each value of the
attributes table must be an attribute_info structure
(§4.7).

A Code attribute
can have any number of optional attributes associated with
it.

The attributes defined by this specification as appearing in
the attributes table of a Code attribute are listed in
Table 4.7-C.

The rules concerning attributes defined to appear in the
attributes table of a Code attribute are given in
§4.7.

The rules concerning non-predefined attributes in the
attributes table of a Code attribute are given in
§4.7.1.

4.7.4. The StackMapTable Attribute

The StackMapTable
attribute is a variable-length attribute in the attributes table of
a Code attribute (§4.7.3). A StackMapTable
attribute is used during the process of verification by type checking
(§4.10.1).

There may be at most one
StackMapTable attribute in the attributes table of a Code
attribute.

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

The value of the
attribute_name_index item must be a valid
index into the constant_pool table. The constant_pool entry
at that index must be a CONSTANT_Utf8_info structure
(§4.4.7) representing the string
"StackMapTable".

attribute_length

The value of the
attribute_length item indicates the length of
the attribute, excluding the initial six bytes.

number_of_entries

The value of the
number_of_entries item gives the number of
stack_map_frame entries in
the entries table.

entries[]

Each entry in
the entries table describes one stack map
frame of the method. The order of the stack map frames in
the entries table is significant.

A stack map frame
specifies (either explicitly or implicitly) the bytecode offset at
which it applies, and the verification types of local variables and
operand stack entries for that offset.

Each stack map frame
described in the entries table relies on the
previous frame for some of its semantics. The first stack map frame of
a method is implicit, and computed from the method descriptor by the
type checker (§4.10.1.6). The
stack_map_frame structure
at entries[0] therefore describes the second stack
map frame of the method.

The bytecode offset at which a stack map frame
applies is calculated by taking the value offset_delta specified in
the frame (either explicitly or implicitly), and
adding offset_delta + 1 to the bytecode offset of
the previous frame, unless the previous frame is the initial frame of
the method. In that case, the bytecode offset at which the stack map
frame applies is the value offset_delta specified in the
frame.

By using an offset delta rather than storing 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 (as opposed to the implicit first frame), 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
contains a stack map frame that applies at bytecode offset
i.

A verification
type specifies the type of either one or two locations,
where a location is either a single local
variable or a single operand stack entry. A verification type is
represented by a discriminated union, verification_type_info, that
consists of a one-byte tag, indicating which item of the union is in
use, followed by zero or more bytes, giving more information about the
tag.

The
Object_variable_info item indicates that the
location has the
verification type which is the class represented by the
CONSTANT_Class_info structure (§4.4.1)
found in the constant_pool table at the index given by
cpool_index.

The
Uninitialized_variable_info item indicates that the location
has the verification type uninitialized(Offset).
The Offset item indicates the offset, in the
code array of the Code attribute that contains this
StackMapTable attribute, of the new instruction
(§new) that created the object being
stored in the location.

A verification type that
specifies two locations in the local variable array or in the operand
stack is represented by the following items of the
verification_type_info union:

The
Long_variable_info item indicates that the first of two
locations has the verification type long.

Long_variable_info {
u1 tag = ITEM_Long; /* 4 */
}

The
Double_variable_info item indicates that the first of two
locations has the verification type double.

Double_variable_info {
u1 tag = ITEM_Double; /* 3 */
}

The
Long_variable_info and Double_variable_info items indicate
the verification type of the second of two locations as
follows:

If the first of
the two locations is a local variable, then:

It must
not be the local variable with the highest index.

The next
higher numbered local variable has the verification type
top.

If the first of
the two locations is an operand stack entry, then:

It must
not be the topmost location of the operand stack.

The next
location closer to the top of the operand stack has the
verification type top.

A stack map frame is
represented by a discriminated union,
stack_map_frame, which consists of a one-byte tag,
indicating which item of the union is in use, followed by zero or more
bytes, giving more information about the tag.

The frame type
same_frame is represented by tags in the range [0-63]. This
frame type indicates that the frame has exactly the same local
variables as the previous frame and that the operand stack is
empty. The offset_delta value for the frame is the value of
the tag item, frame_type.

same_frame {
u1 frame_type = SAME; /* 0-63 */
}

The frame type
same_locals_1_stack_item_frame is represented by tags in the
range [64, 127]. This frame type indicates that the frame has
exactly the same local variables as the previous frame and that
the operand stack has one entry. The offset_delta value for
the frame is given by the formula frame_type -
64. The verification type of the one stack entry
appears after the frame type.

The frame type
same_locals_1_stack_item_frame_extended is represented by the
tag 247. This frame type indicates that the frame has exactly
the same local variables as the previous frame and that the
operand stack has one entry. The offset_delta value for the
frame is given explicitly, unlike in the frame type
same_locals_1_stack_item_frame. The verification type of the
one stack entry appears after offset_delta.

The frame type
chop_frame is represented by tags in the range [248-250]. This
frame type indicates that the frame has the same local variables
as the previous frame except that the last k local
variables are absent, and that the operand stack is empty. The
value of k is given by the formula 251 -
frame_type. The offset_delta value for the frame is
given explicitly.

chop_frame {
u1 frame_type = CHOP; /* 248-250 */
u2 offset_delta;
}

Assume the verification types of local variables in the previous
frame are given by locals, an array
structured as in the full_frame frame type.
If locals[M-1] in the previous frame
represented local variable X and locals[M]
represented local variable Y, then the effect of removing one
local variable is that locals[M-1] in the new
frame represents local variable X and
locals[M] is undefined.

It is an error if k is larger than the number of local variables
in locals for the previous frame, that is, if
the number of local variables in the new frame would be less
than zero.

The frame type
same_frame_extended is represented by the tag 251. This frame
type indicates that the frame has exactly the same local variables
as the previous frame and that the operand stack is empty. The
offset_delta value for the frame is given explicitly, unlike in
the frame type same_frame.

The frame type
append_frame is represented by tags in the range
[252-254]. This frame type indicates that the frame has the same
locals as the previous frame except that k additional
locals are defined, and that the operand stack is empty. The
value of k is given by the formula frame_type -
251. The offset_delta value for the frame is given
explicitly.

The 0th entry in
locals represents the verification type of
the first additional local
variable. If locals[M] represents local
variable N, then:

locals[M+1]
represents local variable N+1
if locals[M] is one of
Top_variable_info, Integer_variable_info,
Float_variable_info, Null_variable_info,
UninitializedThis_variable_info, Object_variable_info,
or Uninitialized_variable_info; and

locals[M+1]
represents local variable N+2
if locals[M] is either
Long_variable_info or Double_variable_info.

It
is an error if, for any index i,
locals[i] represents a local variable
whose index is greater than the maximum number of local
variables for the method.

The frame type
full_frame is represented by the tag 255. The offset_delta
value for the frame is given explicitly.

The 0th entry in
locals represents the verification type of
local variable 0. If locals[M] represents local
variable N, then:

locals[M+1]
represents local variable N+1
if locals[M] is one of
Top_variable_info, Integer_variable_info,
Float_variable_info, Null_variable_info,
UninitializedThis_variable_info, Object_variable_info,
or Uninitialized_variable_info; and

locals[M+1]
represents local variable N+2
if locals[M] is either
Long_variable_info or Double_variable_info.

It
is an error if, for any index i,
locals[i] represents a local variable
whose index is greater than the maximum number of local
variables for the method.

The 0th entry in
stack represents the verification type of the
bottom of the operand stack, and subsequent entries
in stack represent the verification types of
stack entries closer to the top of the operand stack. We refer
to the bottom of the operand stack as stack entry 0, and to
subsequent entries of the operand stack as stack entry 1, 2,
etc. If stack[M] represents stack
entry N, then:

stack[M+1] represents stack
entry N+1 if
stack[M] is one of Top_variable_info,
Integer_variable_info, Float_variable_info,
Null_variable_info, UninitializedThis_variable_info,
Object_variable_info, or Uninitialized_variable_info;
and

stack[M+1]
represents stack entry N+2
if stack[M] is either
Long_variable_info or Double_variable_info.

It
is an error if, for any index i,
stack[i] represents a stack entry whose
index is greater than the maximum operand stack size for the
method.

4.7.5. The Exceptions Attribute

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 the attributes table of a method_info
structure.

The value of the
attribute_name_index item must be a valid
index into the constant_pool table. The constant_pool entry
at that index must be the CONSTANT_Utf8_info structure
(§4.4.7) representing the string
"Exceptions".

attribute_length

The value of
the attribute_length item indicates the
attribute length, excluding the initial six bytes.

number_of_exceptions

The value of the
number_of_exceptions item indicates the
number of entries in
the exception_index_table.

exception_index_table[]

Each value in
the exception_index_table array must be a
valid index into the constant_pool table. The constant_pool
entry at that index must be a CONSTANT_Class_info structure
(§4.4.1) representing a class type that
this method is declared to throw.

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

The exception is an instance of RuntimeException
or one of its subclasses.

The exception is an instance of Error or one
of its subclasses.

The exception is an instance of one of the
exception classes specified in
the exception_index_table just described, or
one of their subclasses.

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

4.7.6. The InnerClasses Attribute

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 at least one CONSTANT_Class_info
entry (§4.4.1) which represents a class or
interface that is not a member of a package, then there must be
exactly one InnerClasses attribute in the attributes table of the
ClassFile structure for C.

The value of the
attribute_name_index item must be a valid
index into the constant_pool table. The constant_pool entry
at that index must be a CONSTANT_Utf8_info structure
(§4.4.7) representing the string
"InnerClasses".

attribute_length

The value of
the attribute_length item indicates the
length of the attribute, excluding the initial six bytes.

number_of_classes

The value of the
number_of_classes item indicates the number
of entries in the classes array.

classes[]

Every
CONSTANT_Class_info entry in the constant_pool table which
represents a class or interface C that is not a package
member must have exactly one corresponding entry in
the classes array.

If a class or interface has members that are
classes or interfaces, its constant_pool table (and hence
its InnerClasses attribute) must refer to each such member
(JLS §13.1), even if that member is not otherwise mentioned by
the class.

In addition, the constant_pool
table of every nested class and nested interface must refer to
its enclosing class, so altogether, every nested class and
nested interface will have InnerClasses information for each
enclosing class and for each of its own nested classes and
interfaces.

Each entry in
the classes array contains the following
four items:

inner_class_info_index

The value
of the inner_class_info_index item must
be a valid index into the constant_pool table. The
constant_pool entry at that index must be a
CONSTANT_Class_info structure representing C. The
remaining items in the classes array
entry give information about C.

outer_class_info_index

If C is
not a member of a class or an interface (that is, if C
is a top-level class or interface (JLS §7.6) or a local
class (JLS §14.3) or an anonymous class (JLS §15.9.5)),
the value of the outer_class_info_index
item must be zero.

Otherwise, the value of
the outer_class_info_index item must be
a valid index into the constant_pool table, and the
entry at that index must be a CONSTANT_Class_info
structure representing the class or interface of which C
is a member.

inner_name_index

If C is
anonymous (JLS §15.9.5), the value of
the inner_name_index item must be
zero.

Otherwise, the value of
the inner_name_index item must be a
valid index into the constant_pool table, and the entry
at that index must be a CONSTANT_Utf8_info structure
(§4.4.7) that represents the
original simple name of C, as given in the source code
from which this class file was compiled.

inner_class_access_flags

The value
of the inner_class_access_flags item is
a mask of flags used to denote access permissions to and
properties of class or interface C as declared in the
source code from which this class file was compiled. It
is used by a compiler to recover the original information
when source code is not available. The flags are specified
in Table 4.7.6-A.

Table 4.7.6-A. Nested class access and property flags

Flag Name

Value

Interpretation

ACC_PUBLIC

0x0001

Marked or implicitly public in source.

ACC_PRIVATE

0x0002

Marked private in source.

ACC_PROTECTED

0x0004

Marked protected in source.

ACC_STATIC

0x0008

Marked or implicitly static in source.

ACC_FINAL

0x0010

Marked final in source.

ACC_INTERFACE

0x0200

Was an interface in source.

ACC_ABSTRACT

0x0400

Marked or implicitly abstract in source.

ACC_SYNTHETIC

0x1000

Declared synthetic; not present in the source
code.

ACC_ANNOTATION

0x2000

Declared as an annotation type.

ACC_ENUM

0x4000

Declared as an enum type.

All bits
of the inner_class_access_flags item
not assigned in Table 4.7.6-A are
reserved for future use. They should be set to zero in
generated class files and should be ignored by Java Virtual Machine
implementations.

If a class file has a version number that is 51.0 or above,
and has an InnerClasses attribute in its attributes table,
then for all entries in the classes array
of the InnerClasses attribute, the value of the
outer_class_info_index item must be zero if
the value of the inner_name_index item is
zero.

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.

4.7.7. The EnclosingMethod Attribute

The EnclosingMethod attribute is
a 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 represents a local class
or an anonymous class (JLS §14.3, JLS §15.9.5).

There may be at most one
EnclosingMethod attribute in the attributes table of a ClassFile
structure.

The value of the
attribute_name_index item must be a valid
index into the constant_pool table. The constant_pool entry
at that index must be a CONSTANT_Utf8_info structure
(§4.4.7) representing the string
"EnclosingMethod".

attribute_length

The value of the
attribute_length item must be four.

class_index

The value of the class_index item must be a
valid index into the constant_pool table. The
constant_pool entry at that index must be a
CONSTANT_Class_info structure (§4.4.1)
representing the innermost class that encloses the declaration
of the current class.

method_index

If the current class
is not immediately enclosed by a method or constructor, then
the value of the method_index item must be
zero.

In
particular, method_index must be zero if
the current class was immediately enclosed in source code by
an instance initializer, static initializer, instance variable
initializer, or class variable initializer. (The first two
concern both local classes and anonymous classes, while the
last two concern anonymous classes declared on the right hand
side of a field assignment.)

Otherwise, the
value of the method_index item must be a
valid index into the constant_pool table. The
constant_pool entry at that index must be a
CONSTANT_NameAndType_info structure
(§4.4.6) representing the name and type
of a method in the class referenced by
the class_index attribute above.

It is the responsibility of a Java compiler to
ensure that the method identified via
the method_index is indeed the closest
lexically enclosing method of the class that contains this
EnclosingMethod attribute.

4.7.8. The Synthetic Attribute

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 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:

attribute_name_index

The value of the
attribute_name_index item must be a valid
index into the constant_pool table. The constant_pool entry
at that index must be a CONSTANT_Utf8_info structure
(§4.4.7) representing the string
"Synthetic".

attribute_length

The value of the
attribute_length item must be zero.

4.7.9. The Signature Attribute

The Signature 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 Signature
attribute records a signature (§4.7.9.1) for a
class, interface, constructor, method, or field whose declaration in
the Java programming language uses type variables or parameterized types. See The Java Language Specification, Java SE 8 Edition
for details about these types.

The value of
the attribute_name_index item must be a valid
index into the constant_pool table. The constant_pool entry
at that index must be a CONSTANT_Utf8_info structure
(§4.4.7) representing the string
"Signature".

attribute_length

The value of the
attribute_length item of a
Signature_attribute structure must be
two.

signature_index

The value of the
signature_index item must be a valid index
into the constant_pool table. The constant_pool entry at
that index must be a CONSTANT_Utf8_info structure
(§4.4.7) representing a class signature if
this Signature attribute is an attribute of a ClassFile
structure; a method signature if this Signature attribute is
an attribute of a method_info structure; or a field signature
otherwise.

Oracle's Java Virtual Machine implementation does not check the
well-formedness of Signature attributes during class loading or
linking. Instead, Signature attributes are checked by methods of the
Java SE platform class libraries which expose generic signatures of classes,
interfaces, constructors, methods, and fields. Examples
include getGenericSuperclass in Class
and toGenericString
in java.lang.reflect.Executable.

4.7.9.1. Signatures

Signatures encode declarations written in the
Java programming language that use types outside the type system of the Java Virtual Machine. They
support reflection and debugging, as well as compilation when only
class files are available.

A Java compiler must
emit a signature for any class,
interface, constructor, method, or field whose declaration uses type variables or parameterized
types. Specifically, a Java compiler must emit:

A class signature
for any class or interface declaration which is either generic,
or has a parameterized type as a superclass or superinterface,
or both.

A method signature
for any method or constructor declaration which is either
generic, or has a type variable or parameterized type as the
return type or a formal parameter type, or has a type variable
in a throws clause, or any combination thereof.

If the throws
clause of a method or constructor declaration does not involve
type variables, then a compiler may treat the declaration as
having no throws clause for the purpose of emitting a method
signature.

A field signature
for any field, formal parameter, or local variable declaration
whose type uses a type variable or a parameterized type.

Signatures are specified
using a grammar which follows the notation of
§4.3.1. In addition to that notation:

The
syntax [x] on the right-hand side of a
production denotes zero or one occurrences
of x. That is, x is
an optional symbol. The alternative which
contains the optional symbol actually defines two alternatives:
one that omits the optional symbol and one that includes
it.

A very long
right-hand side may be continued on a second line by clearly
indenting the second line.

The grammar includes the
terminal symbol Identifier to denote the name of a type, field,
method, formal parameter, local variable, 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).

Signatures rely on a
hierarchy of nonterminals known as type
signatures:

A Java
type signature represents either a reference type or
a primitive type of the Java programming language.

The following production from
§4.3.2 is repeated here for
convenience:

BaseType:

(one of) BCDFIJSZ

A reference type
signature represents a reference type of the
Java programming language, that is, a class or interface type, a type variable,
or an array type.

A class
type signature represents a (possibly parameterized)
class or interface type. A 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 to a $ character.

A class
signature encodes type information about a (possibly
generic) class declaration. It describes any type parameters of the
class, and lists its (possibly parameterized) direct superclass and
direct superinterfaces, if any. A type parameter is described by its
name, followed by any class bound and interface bounds.

A method
signature encodes type information about a (possibly
generic) method declaration. It describes any type parameters of the
method; the (possibly parameterized) types of any formal parameters;
the (possibly parameterized) return type, if any; and the types of any
exceptions declared in the method's throws clause.

The following production from
§4.3.3 is repeated here for convenience:

VoidDescriptor:

V

Due to compiler-generated artifacts, the method
signature of a method may not correspond exactly to the method
descriptor of the method (§4.3.3). In
particular, the number of formal parameter types in the method
signature may be less than the number of parameter descriptors in the
method descriptor.

A field
signature encodes the (possibly parameterized) type of a
field, formal parameter, or local variable declaration.

The value of the
attribute_name_index item must be a valid
index into the constant_pool table. The constant_pool
entry at that index must be a CONSTANT_Utf8_info structure
(§4.4.7) representing the string
"SourceFile".

attribute_length

The value of
the attribute_length item of
a SourceFile_attribute structure must be
two.

sourcefile_index

The value of the
sourcefile_index item must be a valid index
into the constant_pool table. The constant_pool entry at
that index must be a CONSTANT_Utf8_info structure
(§4.4.7) representing a string.

The string referenced by
the sourcefile_index item will be
interpreted as indicating the name of the source file from
which this class file was compiled. It will not be
interpreted as indicating the name of a directory containing
the file or an absolute path name for the file; such
platform-specific additional information must be supplied by
the run-time interpreter or development tool at the time the
file name is actually used.

4.7.11. The SourceDebugExtension Attribute

The SourceDebugExtension
attribute is an optional attribute in the attributes table of a
ClassFile structure (§4.1).

There may be at most one
SourceDebugExtension attribute in the attributes table of a
ClassFile structure.

The items of
the SourceDebugExtension_attribute structure are as
follows:

attribute_name_index

The value of the
attribute_name_index item must be a valid
index into the constant_pool table. The constant_pool entry
at that index must be a CONSTANT_Utf8_info structure
(§4.4.7) representing the string
"SourceDebugExtension".

attribute_length

The value of the
attribute_length item indicates the length of
the attribute, excluding the initial six bytes.

debug_extension[]

The debug_extension
array holds extended debugging information which has no semantic
effect on the Java Virtual Machine. The information is represented using a
modified UTF-8 string (§4.4.7) with no
terminating zero byte.

Note that
the debug_extension array may denote a string
longer than that which can be represented with an instance of
class String.

4.7.12. The LineNumberTable Attribute

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

If multiple
LineNumberTable attributes are present in the attributes table of
a Code attribute, then they may appear in any order.

There may be more than one
LineNumberTable attribute per line of a source
file in the attributes table of a Code attribute. That
is, LineNumberTable attributes may together represent a given line
of a source file, and need not be one-to-one with source lines.

The value of the
attribute_name_index item must be a valid
index into the constant_pool table. The constant_pool entry
at that index must be a CONSTANT_Utf8_info structure
(§4.4.7) representing the string
"LineNumberTable".

attribute_length

The value of the
attribute_length item indicates the length of
the attribute, excluding the initial six bytes.

line_number_table_length

The value of the
line_number_table_length item indicates the
number of entries in the line_number_table
array.

line_number_table[]

Each entry in the
line_number_table array indicates that the
line number in the original source file changes at a given point
in the code array. Each line_number_table
entry must contain the following two items:

start_pc

The value
of the start_pc item must indicate the
index into the code array at which the code for a new
line in the original source file begins.

The value
of start_pc must be less than the value
of the code_length item of the Code
attribute of which this LineNumberTable is an
attribute.

line_number

The value
of the line_number item must give the
corresponding line number in the original source
file.

4.7.13. The LocalVariableTable Attribute

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

If multiple
LocalVariableTable attributes are present in the attributes table
of a Code attribute, then they may appear in any order.

There may be no more than
one LocalVariableTable attribute per local
variable in the attributes table of a Code
attribute.

The items of
the LocalVariableTable_attribute structure are as
follows:

attribute_name_index

The value of the
attribute_name_index item must be a valid
index into the constant_pool table. The constant_pool entry
at that index must be a CONSTANT_Utf8_info structure
(§4.4.7) representing the string
"LocalVariableTable".

attribute_length

The value of the
attribute_length item indicates the length of
the attribute, excluding the initial six bytes.

local_variable_table_length

The value of the
local_variable_table_length item indicates
the number of entries in
the local_variable_table array.

local_variable_table[]

Each entry in the
local_variable_table array indicates a range
of code array offsets within which a local variable has a
value. It also indicates the index into the local variable array
of the current frame at which that local variable can be
found. Each entry must contain the following five items:

start_pc, length

The given
local variable must have a value at indices into the
code array in the interval
[start_pc, start_pc +
length), that is,
between start_pc inclusive
and start_pc + length exclusive.

The value
of start_pc must be a valid index into
the code array of this Code attribute and must be the
index of the opcode of an instruction.

The value of
start_pc + length must either be a
valid index into the code array of this Code attribute
and be the index of the opcode of an instruction, or it
must be the first index beyond the end of that code
array.

name_index

The value
of the name_index item must be a valid
index into the constant_pool table. The constant_pool
entry at that index must contain a CONSTANT_Utf8_info
structure (§4.4.7) representing a
valid unqualified name denoting a local variable
(§4.2.2).

descriptor_index

The value
of the descriptor_index item must be a
valid index into the constant_pool table. The
constant_pool entry at that index must contain a
CONSTANT_Utf8_info structure
(§4.4.7) representing a field
descriptor which encodes the type of a local variable in
the source program (§4.3.2).

index

The given
local variable must be at index in the
local variable array of the current frame.

If the
local variable at index is of type
double or long, it occupies
both index and index +
1.

4.7.14. The LocalVariableTypeTable Attribute

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

If multiple
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 attributes table of a Code
attribute.

The LocalVariableTypeTable attribute differs from
the LocalVariableTable attribute (§4.7.13) in
that it provides signature information rather than descriptor
information. This difference is only significant for variables whose
type uses a type variable or parameterized type. Such variables will
appear in both tables, while variables of other types will appear only
in LocalVariableTable.

The items of
the LocalVariableTypeTable_attribute structure are
as follows:

attribute_name_index

The value of the
attribute_name_index item must be a valid
index into the constant_pool table. The constant_pool entry
at that index must be a CONSTANT_Utf8_info structure
(§4.4.7) representing the string
"LocalVariableTypeTable".

attribute_length

The value of the
attribute_length item indicates the length of
the attribute, excluding the initial six bytes.

local_variable_type_table_length

The value of the
local_variable_type_table_length item
indicates the number of entries in
the local_variable_type_table array.

local_variable_type_table[]

Each entry in the
local_variable_type_table array indicates a
range of code array offsets within which a local variable has
a value. It also indicates the index into the local variable
array of the current frame at which that local variable can be
found. Each entry must contain the following five items:

start_pc, length

The given
local variable must have a value at indices into the
code array in the interval
[start_pc, start_pc +
length), that is,
between start_pc inclusive
and start_pc + length exclusive.

The value
of start_pc must be a valid index into
the code array of this Code attribute and must be the
index of the opcode of an instruction.

The value
of start_pc + length must either be a
valid index into the code array of this Code attribute
and be the index of the opcode of an instruction, or it
must be the first index beyond the end of that code
array.

name_index

The value
of the name_index item must be a valid
index into the constant_pool table. The constant_pool
entry at that index must contain a CONSTANT_Utf8_info
structure (§4.4.7) representing a
valid unqualified name denoting a local variable
(§4.2.2).

signature_index

The value
of the signature_index item must be a
valid index into the constant_pool table. The
constant_pool entry at that index must contain a
CONSTANT_Utf8_info structure
(§4.4.7) representing a field
signature which encodes the type of a local variable in
the source program
(§4.7.9.1).

index

The given
local variable must be at index in the
local variable array of the current frame.

If the
local variable at index is of type
double or long, it occupies
both index and index +
1.

4.7.15. The Deprecated Attribute

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 superseded 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 value of the
attribute_name_index item must be a valid
index into the constant_pool table. The constant_pool entry
at that index must be a CONSTANT_Utf8_info structure
(§4.4.7) representing the string
"Deprecated".

attribute_length

The value of the
attribute_length item must be zero.

4.7.16. The RuntimeVisibleAnnotations Attribute

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
annotations on the declaration of the corresponding class, field, or
method. The Java Virtual Machine must make these annotations available so they can be
returned by the appropriate reflective APIs.

There may be at most one
RuntimeVisibleAnnotations attribute in the attributes table of a
ClassFile, field_info, or method_info structure.

The items of
the RuntimeVisibleAnnotations_attribute structure
are as follows:

attribute_name_index

The value of the
attribute_name_index item must be a valid
index into the constant_pool table. The constant_pool entry
at that index must be a CONSTANT_Utf8_info structure
(§4.4.7) representing the string
"RuntimeVisibleAnnotations".

attribute_length

The value of the
attribute_length item indicates the length
of the attribute, excluding the initial six bytes.

num_annotations

The value of the
num_annotations item gives the number of
run-time visible annotations represented by the
structure.

annotations[]

Each entry in the
annotations table represents a single
run-time visible annotation on a
declaration. The annotation structure has
the following format:

The value
of the type_index item must be a
valid index into the constant_pool table. The
constant_pool entry at that index must be a
CONSTANT_Utf8_info structure
(§4.4.7) representing a field
descriptor (§4.3.2). The field
descriptor denotes the type of the annotation
represented by this annotation
structure.

num_element_value_pairs

The value
of the num_element_value_pairs item
gives the number of element-value pairs of the annotation
represented by this annotation
structure.

element_value_pairs[]

Each
value of the element_value_pairs table
represents a single element-value pair in the annotation
represented by this annotation
structure. Each element_value_pairs
entry contains the following two items:

element_name_index

The value of the
element_name_index item must be
a valid index into the constant_pool table. The
constant_pool entry at that index must be a
CONSTANT_Utf8_info structure
(§4.4.7). The
constant_pool entry denotes the name of the
element of the element-value pair represented by
this element_value_pairs
entry.

In other words, the entry denotes
an element of the annotation type specified
by type_index.

value

The value of
the value item represents the
value of the element-value pair represented by this
element_value_pairs entry.

4.7.16.1. The element_value structure

The
element_value structure is a discriminated union
representing the value of an element-value pair. It has the following
format:

The tag item uses a single ASCII
character to indicate the type of the value of the element-value
pair. This determines which item of the value union
is in use. Table 4.7.16.1-A shows the valid
characters for the tag item, the type indicated by each character,
and the item used in the value union for each
character. The table's fourth column is used in the description below
of one item of the value union.

Table 4.7.16.1-A. Interpretation of tag values as types

tag Item

Type

value Item

Constant Type

B

byte

const_value_index

CONSTANT_Integer

C

char

const_value_index

CONSTANT_Integer

D

double

const_value_index

CONSTANT_Double

F

float

const_value_index

CONSTANT_Float

I

int

const_value_index

CONSTANT_Integer

J

long

const_value_index

CONSTANT_Long

S

short

const_value_index

CONSTANT_Integer

Z

boolean

const_value_index

CONSTANT_Integer

s

String

const_value_index

CONSTANT_Utf8

e

Enum type

enum_const_value

Not applicable

c

Class

class_info_index

Not applicable

@

Annotation type

annotation_value

Not applicable

[

Array type

array_value

Not applicable

The
value item represents the value of an element-value
pair. The item is a union, whose own items are as follows:

const_value_index

The const_value_index item denotes either a
primitive constant value or a String literal as the value of
this element-value pair.

The value of the const_value_index item
must be a valid index into the constant_pool table. The
constant_pool entry at that index must be of a type
appropriate to the tag item, as specified in the fourth
column of Table 4.7.16.1-A.

enum_const_value

The enum_const_value item denotes an enum
constant as the value of this element-value pair.

The
enum_const_value item consists of the
following two items:

type_name_index

The value of the type_name_index item
must be a valid index into the constant_pool
table. The constant_pool entry at that index must be a
CONSTANT_Utf8_info structure
(§4.4.7) representing a field
descriptor (§4.3.2). The
constant_pool entry gives the internal form of the
binary name of the type of the enum constant represented
by this element_value structure
(§4.2.1).

const_name_index

The value of the const_name_index
item must be a valid index into the constant_pool
table. The constant_pool entry at that index must be a
CONSTANT_Utf8_info structure
(§4.4.7). The constant_pool
entry gives the simple name of the enum constant
represented by this element_value
structure.

class_info_index

The class_info_index item denotes a class
literal as the value of this element-value pair.

The
class_info_index item must be a valid index
into the constant_pool table. The constant_pool entry at
that index must be a CONSTANT_Utf8_info structure
(§4.4.7) representing a return
descriptor (§4.3.3). The return
descriptor gives the type corresponding to the class literal
represented by this element_value
structure. Types correspond to class literals as
follows:

For a class literal C.class, where C is the name
of a class, interface, or array type, the corresponding
type is C. The return descriptor in the constant_pool
will be an ObjectType or
an ArrayType.

For a class literal p.class,
where p is the name of a primitive type, the
corresponding type is p. The return
descriptor in the constant_pool will be
a BaseType character.

For a class literal void.class, the corresponding
type is void. The return descriptor in the
constant_pool will be V.

For example, the class literal
Object.class corresponds to the type
Object, so the constant_pool entry
is Ljava/lang/Object;, whereas the class
literal int.class corresponds to the type
int, so the constant_pool entry is I.

The class literal
void.class corresponds to void, so the
constant_pool entry is V, whereas the
class literal Void.class corresponds to the
type Void, so the constant_pool entry
is Ljava/lang/Void;.

annotation_value

The annotation_value item denotes a
"nested" annotation as the value of this element-value
pair.

The value of the annotation_value item is an
annotation structure
(§4.7.16) that gives the annotation
represented by this element_value
structure.

array_value

The array_value item denotes an array as
the value of this element-value pair.

The array_value item consists of the
following two items:

num_values

The value of the num_values item
gives the number of elements in the array represented by
this element_value structure.

values[]

Each value in the values table gives
the corresponding element of the array represented by
this element_value structure.

4.7.17. The RuntimeInvisibleAnnotations 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
annotations on the declaration of the corresponding class, method, or
field.

There may be at most one
RuntimeInvisibleAnnotations attribute in the attributes table of a
ClassFile, field_info, or method_info structure.

The RuntimeInvisibleAnnotations attribute is
similar to the RuntimeVisibleAnnotations attribute
(§4.7.16), 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 items of
the RuntimeInvisibleAnnotations_attribute structure
are as follows:

attribute_name_index

The value of the
attribute_name_index item must be a valid
index into the constant_pool table. The constant_pool entry
at that index must be a CONSTANT_Utf8_info structure
(§4.4.7) representing the string
"RuntimeInvisibleAnnotations".

attribute_length

The value of the
attribute_length item indicates the length of
the attribute, excluding the initial six bytes.

num_annotations

The value of the
num_annotations item gives the number of
run-time invisible annotations represented by the
structure.

annotations[]

Each entry in the
annotations table represents a single
run-time invisible annotation on a
declaration. The annotation structure is
specified in §4.7.16.

4.7.18. The RuntimeVisibleParameterAnnotations Attribute

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 annotations on the declarations of
formal parameters of the corresponding method. The Java Virtual Machine must make
these annotations available so they can be returned by the appropriate
reflective APIs.

There may be at most one
RuntimeVisibleParameterAnnotations attribute in the attributes
table of a method_info structure.

The
RuntimeVisibleParameterAnnotations attribute has the following
format:

The items of
the RuntimeVisibleParameterAnnotations_attribute
structure are as follows:

attribute_name_index

The value of the
attribute_name_index item must be a valid
index into the constant_pool table. The constant_pool
entry at that index must be a CONSTANT_Utf8_info structure
(§4.4.7) representing the string
"RuntimeVisibleParameterAnnotations".

attribute_length

The value of the
attribute_length item indicates the length
of the attribute, excluding the initial six bytes.

num_parameters

The value of the
num_parameters item gives the number of
formal parameters of the method represented by the
method_info structure on which the annotation occurs.

This duplicates information that could be
extracted from the method descriptor.

parameter_annotations[]

Each entry in the
parameter_annotations table represents all
of the run-time visible annotations on the declaration of a
single formal parameter. The i'th entry in the table
corresponds to the i'th formal parameter in the method
descriptor (§4.3.3). Each
parameter_annotations entry contains the
following two items:

num_annotations

The value
of the num_annotations item indicates
the number of run-time visible annotations on the
declaration of the formal parameter corresponding to the
parameter_annotations entry.

annotations[]

Each entry
in the annotations table represents a
single run-time visible annotation on the declaration of
the formal parameter corresponding to
the parameter_annotations
entry. The annotation structure is
specified in §4.7.16.

4.7.19. The RuntimeInvisibleParameterAnnotations 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 annotations on the declarations of formal parameters of the
corresponding method.

There may be at most one
RuntimeInvisibleParameterAnnotations attribute in the attributes
table of a method_info structure.

The RuntimeInvisibleParameterAnnotations attribute
is similar to the RuntimeVisibleParameterAnnotations attribute
(§4.7.18), 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 has the following
format:

The items of
the RuntimeInvisibleParameterAnnotations_attribute
structure are as follows:

attribute_name_index

The value of the
attribute_name_index item must be a valid
index into the constant_pool table. The constant_pool entry
at that index must be a CONSTANT_Utf8_info structure
(§4.4.7) representing the string
"RuntimeInvisibleParameterAnnotations".

attribute_length

The value of the
attribute_length item indicates the length
of the attribute, excluding the initial six bytes.

num_parameters

The value of the
num_parameters item gives the number of
formal parameters of the method represented by the
method_info structure on which the annotation occurs.

This duplicates information that could be
extracted from the method descriptor.

parameter_annotations[]

Each entry in the
parameter_annotations table represents all
of the run-time invisible annotations on the declaration of a
single formal parameter. The i'th entry in the table
corresponds to the i'th formal parameter in the method
descriptor (§4.3.3). Each
parameter_annotations entry contains the
following two items:

num_annotations

The value
of the num_annotations item indicates
the number of run-time invisible annotations on the
declaration of the formal parameter corresponding to the
parameter_annotations entry.

annotations[]

Each entry
in the annotations table represents a
single run-time invisible annotation on the declaration
of the formal parameter corresponding to the
parameter_annotations
entry. The annotation structure is
specified in §4.7.16.

4.7.20. The RuntimeVisibleTypeAnnotations Attribute

The
RuntimeVisibleTypeAnnotations attribute is an variable-length
attribute in the attributes table of a ClassFile, field_info, or
method_info structure, or Code attribute
(§4.1, §4.5,
§4.6, §4.7.3). The
RuntimeVisibleTypeAnnotations attribute records run-time visible
annotations on types used in the declaration of the corresponding
class, field, or method, or in an expression in the corresponding
method body. The RuntimeVisibleTypeAnnotations attribute also
records run-time visible annotations on type parameter declarations of
generic classes, interfaces, methods, and constructors. The Java Virtual Machine must
make these annotations available so they can be returned by the
appropriate reflective APIs.

There may be at most one
RuntimeVisibleTypeAnnotations attribute in the attributes table of
a ClassFile, field_info, or method_info structure, or Code
attribute.

An attributes table
contains a RuntimeVisibleTypeAnnotations attribute only if types are
annotated in kinds of declaration or expression that correspond to the
parent structure or attribute of the attributes table.

For example, all annotations on types in the
implements clause of a class declaration are recorded in the
RuntimeVisibleTypeAnnotations attribute of the class's ClassFile
structure. Meanwhile, all annotations on the type in a field
declaration are recorded in the RuntimeVisibleTypeAnnotations
attribute of the field's field_info structure.

The items of
the RuntimeVisibleTypeAnnotations_attribute
structure are as follows:

attribute_name_index

The value of the
attribute_name_index item must be a valid
index into the constant_pool table. The constant_pool
entry at that index must be a CONSTANT_Utf8_info structure
representing the string "RuntimeVisibleTypeAnnotations".

attribute_length

The value of the attribute_length item
indicates the length of the attribute, excluding the initial
six bytes.

num_annotations

The value of the num_annotations item gives
the number of run-time visible type annotations represented by
the structure.

annotations[]

Each entry in the annotations table
represents a single run-time visible annotation on a type used
in a declaration or expression. The
type_annotation structure has the following
format:

The first three items - target_type, target_info,
and target_path - specify the precise
location of the annotated type. The last three items
- type_index,
num_element_value_pairs,
and element_value_pairs[] - specify the
annotation's own type and element-value pairs.

The items of the type_annotation structure
are as follows:

target_type

The value of the target_type item denotes the kind of
target on which the annotation appears. The various
kinds of target correspond to the type
contexts of the Java programming language where types are
used in declarations and expressions (JLS §4.11).

The legal values of target_type are specified in
Table 4.7.20-A and
Table 4.7.20-B. Each value is a
one-byte tag indicating which item of the target_info
union follows the target_type item to give more
information about the target.

The value of the target_type item determines whether
the type_annotation structure appears
in a RuntimeVisibleTypeAnnotations attribute in a
ClassFile structure, a field_info structure, a
method_info structure, or a Code
attribute. Table 4.7.20-C gives the
location of the RuntimeVisibleTypeAnnotations
attribute for a type_annotation
structure with each legal target_type value.

target_info

The value
of the target_info item denotes precisely which type
in a declaration or expression is annotated.

4.7.20.1. The target_info union

The items of the
target_info union (except for the first) specify precisely which
type in a declaration or expression is annotated. The first item
specifies not which type, but rather which declaration of a type
parameter is annotated. The items are as follows:

The type_parameter_target item indicates that an annotation
appears on the declaration of the i'th type parameter of a
generic class, generic interface, generic method, or generic
constructor.

type_parameter_target {
u1 type_parameter_index;
}

The value of the type_parameter_index item
specifies which type parameter declaration is
annotated. A type_parameter_index value of
0 specifies the first type parameter declaration.

The supertype_target item indicates that an annotation appears
on a type in the extends or implements clause of a class or
interface declaration.

supertype_target {
u2 supertype_index;
}

A supertype_index value of 65535 specifies
that the annotation appears on the superclass in an extends
clause of a class declaration.

Any other supertype_index value is an index
into the interfaces array of the enclosing
ClassFile structure, and specifies that the annotation appears
on that superinterface in either the implements clause of a
class declaration or the extends clause of an interface
declaration.

The type_parameter_bound_target item indicates that an
annotation appears on the i'th bound of the j'th type
parameter declaration of a generic class, interface, method, or
constructor.

The value of the of type_parameter_index item
specifies which type parameter declaration has an annotated
bound. A type_parameter_index value of 0
specifies the first type parameter declaration.

The value of the bound_index item specifies
which bound of the type parameter declaration indicated
by type_parameter_index is
annotated. A bound_index value of 0
specifies the first bound of a type parameter
declaration.

The type_parameter_bound_target item records
that a bound is annotated, but does not record the type which
constitutes the bound. The type may be found by inspecting the
class signature or method signature stored in the appropriate
Signature attribute.

The empty_target item indicates that an annotation appears on
either the type in a field declaration, the return type of a
method, the type of a newly constructed object, or the receiver
type of a method or constructor.

empty_target {
}

Only one type appears in each of these
locations, so there is no per-type information to represent in
the target_info union.

The formal_parameter_target item indicates that an annotation
appears on the type in a formal parameter declaration of a
method, constructor, or lambda expression.

formal_parameter_target {
u1 formal_parameter_index;
}

The value of the formal_parameter_index item
specifies which formal parameter declaration has an annotated
type. A formal_parameter_index value of
0 specifies the first formal parameter declaration.

The formal_parameter_target item records that
a formal parameter's type is annotated, but does not record the
type itself. The type may be found by inspecting the method
descriptor (§4.3.3) of the method_info
structure enclosing the RuntimeVisibleTypeAnnotations
attribute. A formal_parameter_index value of
0 indicates the first parameter descriptor in the method
descriptor.

The throws_target item indicates that an annotation appears on
the i'th type in the throws clause of a method or
constructor declaration.

throws_target {
u2 throws_type_index;
}

The value of the throws_type_index item is an
index into the exception_index_table array of
the Exceptions attribute of the method_info structure
enclosing the RuntimeVisibleTypeAnnotations attribute.

The localvar_target item indicates that an annotation appears
on the type in a local variable declaration, including a
variable declared as a resource in a try-with-resources
statement.

The value of the table_length item gives the
number of entries in the table array. Each
entry indicates a range of code array offsets within which a
local variable has a value. It also indicates the index into the
local variable array of the current frame at which that local
variable can be found. Each entry contains the following three
items:

start_pc, length

The given local variable has a value at indices into the
code array in the interval
[start_pc, start_pc +
length), that is,
between start_pc inclusive
and start_pc + length exclusive.

index

The given local variable must be
at index in the local variable array of
the current frame.

If the local variable at index is of
type double or long, it occupies
both index and index +
1.

A table is needed to fully specify the local
variable whose type is annotated, because a single local
variable may be represented with different local variable
indices over multiple live ranges. The
start_pc, length,
and index items in each table entry specify
the same information as a LocalVariableTable attribute.

The localvar_target item records that a local
variable's type is annotated, but does not record the type
itself. The type may be found by inspecting the appropriate
LocalVariableTable attribute.

The catch_target item indicates that an annotation appears on
the i'th type in an exception parameter declaration.

catch_target {
u2 exception_table_index;
}

The value of the exception_table_index item
is an index into the exception_table array of
the Code attribute enclosing the
RuntimeVisibleTypeAnnotations attribute.

The possibility of more than one type in an
exception parameter declaration arises from the multi-catch
clause of the try statement, where the type of the exception
parameter is a union of types (JLS §14.20). A compiler usually
creates one exception_table entry for each
type in the union, which allows the catch_target item to
distinguish them. This preserves the correspondence between a
type and its annotations.

The offset_target item indicates that an annotation appears on
either the type in an instanceof expression or a new
expression, or the type before the :: in a
method reference expression.

offset_target {
u2 offset;
}

The value of the offset item specifies the
code array offset of either the instanceof bytecode
instruction corresponding to the instanceof expression, the
new bytecode instruction corresponding to the new
expression, or the bytecode instruction corresponding to the
method reference expression.

The type_argument_target item indicates that an annotation
appears either on the i'th type in a cast expression, or on
the i'th type argument in the explicit type argument list
for any of the following: a new expression, an explicit
constructor invocation statement, a method invocation
expression, or a method reference expression.

type_argument_target {
u2 offset;
u1 type_argument_index;
}

The value of the offset item specifies the
code array offset of either the bytecode instruction
corresponding to the cast expression, the new bytecode
instruction corresponding to the new expression, the bytecode
instruction corresponding to the explicit constructor invocation
statement, the bytecode instruction corresponding to the method
invocation expression, or the bytecode instruction corresponding
to the method reference expression.

For a cast expression, the value of
the type_argument_index item specifies which
type in the cast operator is
annotated. A type_argument_index value of
0 specifies the first (or only) type in the cast
operator.

The possibility of more than one type in a cast
expression arises from a cast to an intersection type.

For an explicit type argument list, the value of
the type_argument_index item specifies which
type argument is annotated. A
type_argument_index value of 0 specifies
the first type argument.

4.7.20.2. The type_path structure

Wherever a type is used
in a declaration or expression, the type_path structure identifies
which part of the type is annotated. An annotation may appear on the
type itself, but if the type is a reference type, then there are
additional locations where an annotation may appear:

If an array type T[] is used in a
declaration or expression, then an annotation may appear on any
component type of the array type, including the element
type.

If a nested type T1.T2 is used in a declaration
or expression, then an annotation may appear on the name of the
top level type or any member type.

If a parameterized type T<A>
or T<? extends A>
or T<? super A> is used in a
declaration or expression, then an annotation may appear on any
type argument or on the bound of any wildcard type
argument.

For example, consider the different parts of
String[][] that are annotated in:

The value of
the path_length item gives the number of entries in
the path array:

If the value of path_length is 0, then
the annotation appears directly on the type itself.

If the value of path_length is non-zero, then
each entry in the path array represents an
iterative, left-to-right step towards the precise location of
the annotation in an array type, nested type, or parameterized
type. (In an array type, the iteration visits the array type
itself, then its component type, then the component type of that
component type, and so on, until the element type is reached.)
Each entry contains the following two items:

Annotation is on the bound of a wildcard type
argument of a parameterized type

3

Annotation is on a type argument of a
parameterized type

type_argument_index

If the value of the type_path_kind item
is 0, 1, or 2, then the value of
the type_argument_index item is
0.

If the value of the type_path_kind item
is 3, then the value of
the type_argument_index item specifies
which type argument of a parameterized type is annotated,
where 0 indicates the first type argument of a
parameterized type.

4.7.21. The RuntimeInvisibleTypeAnnotations Attribute

The
RuntimeInvisibleTypeAnnotations attribute is an variable-length
attribute in the attributes table of a ClassFile, field_info, or
method_info structure, or Code attribute
(§4.1, §4.5,
§4.6, §4.7.3). The
RuntimeInvisibleTypeAnnotations attribute records run-time invisible
annotations on types used in the corresponding declaration of a class,
field, or method, or in an expression in the corresponding method
body. The RuntimeInvisibleTypeAnnotations attribute also records
annotations on type parameter declarations of generic classes,
interfaces, methods, and constructors.

There may be at most one
RuntimeInvisibleTypeAnnotations attribute in the attributes table
of a ClassFile, field_info, or method_info structure, or Code
attribute.

An attributes table contains a
RuntimeInvisibleTypeAnnotations attribute only if types are
annotated in kinds of declaration or expression that correspond to the
parent structure or attribute of the attributes table.

The
RuntimeInvisibleTypeAnnotations attribute has the following
format:

The items of
the RuntimeInvisibleTypeAnnotations_attribute
structure are as follows:

attribute_name_index

The value of the attribute_name_index item
must be a valid index into the constant_pool table. The
constant_pool entry at that index must be a
CONSTANT_Utf8_info structure representing the string
"RuntimeInvisibleTypeAnnotations".

attribute_length

The value of the attribute_length item
indicates the length of the attribute, excluding the initial
six bytes.

num_annotations

The value of the num_annotations item gives
the number of run-time invisible type annotations represented
by the structure.

annotations[]

Each entry in the annotations table
represents a single run-time invisible annotation on a type
used in a declaration or expression. The
type_annotation structure is specified in
§4.7.20.

4.7.22. The AnnotationDefault Attribute

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 (JLS §9.6.1). The
AnnotationDefault attribute records the default value (JLS §9.6.2)
for the element represented by the method_info structure. The Java Virtual Machine
must make this default value available so it can be applied by
appropriate reflective APIs.

There may be at most one
AnnotationDefault attribute in the attributes table of a
method_info structure which represents an element of an annotation
type.

The items of
the AnnotationDefault_attribute structure are as
follows:

attribute_name_index

The value of the
attribute_name_index item must be a valid
index into the constant_pool table. The constant_pool
entry at that index must be a CONSTANT_Utf8_info structure
(§4.4.7) representing the string
"AnnotationDefault".

attribute_length

The value of the
attribute_length item indicates the length
of the attribute, excluding the initial six bytes.

default_value

The
default_value item represents the default
value of the annotation type element represented by the
method_info structure enclosing this AnnotationDefault
attribute.

4.7.23. The BootstrapMethods Attribute

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
ClassFile structure if the constant_pool table of the ClassFile
structure has at least one CONSTANT_InvokeDynamic_info entry
(§4.4.10).

There may be at most one
BootstrapMethods attribute in the attributes table of a
ClassFile structure.

The value of the
attribute_name_index item must be a valid
index into the constant_pool table. The constant_pool entry
at that index must be a CONSTANT_Utf8_info structure
(§4.4.7) representing the string
"BootstrapMethods".

attribute_length

The value of the
attribute_length item indicates the length of
the attribute, excluding the initial six bytes.

The value of the
attribute_length item is thus dependent on
the number of invokedynamic instructions in this ClassFile
structure.

num_bootstrap_methods

The value of the
num_bootstrap_methods item determines the
number of bootstrap method specifiers in
the bootstrap_methods array.

bootstrap_methods[]

Each entry in the
bootstrap_methods table contains an index to
a CONSTANT_MethodHandle_info structure
(§4.4.8) which specifies a bootstrap
method, and a sequence (perhaps empty) of indexes
to static arguments for the bootstrap
method.

Each
bootstrap_methods entry must contain the
following three items:

bootstrap_method_ref

The value
of the bootstrap_method_ref item must
be a valid index into the constant_pool table. The
constant_pool entry at that index must be a
CONSTANT_MethodHandle_info structure
(§4.4.8).

The form of the method handle is
driven by the continuing resolution of the call site
specifier in §invokedynamic,
where execution of invoke in java.lang.invoke.MethodHandle requires
that the bootstrap method handle be adjustable to the
actual arguments being passed, as if by a call to
java.lang.invoke.MethodHandle.asType. Accordingly,
the reference_kind item of the
CONSTANT_MethodHandle_info structure should have the
value 6 or 8 (§5.4.3.5), and
the reference_index item should
specify a static method or constructor that takes three
arguments of type java.lang.invoke.MethodHandles.Lookup, String, and
java.lang.invoke.MethodType, in that order. Otherwise, invocation of
the bootstrap method handle during call site specifier
resolution will complete abruptly.

num_bootstrap_arguments

The value
of the num_bootstrap_arguments item
gives the number of items in
the bootstrap_arguments array.

bootstrap_arguments[]

Each
entry in the bootstrap_arguments array
must be a valid index into the constant_pool table. The
constant_pool entry at that index must be a
CONSTANT_String_info, CONSTANT_Class_info,
CONSTANT_Integer_info, CONSTANT_Long_info,
CONSTANT_Float_info, CONSTANT_Double_info,
CONSTANT_MethodHandle_info, or
CONSTANT_MethodType_info structure
(§4.4.3,
§4.4.1,
§4.4.4,
§4.4.5,
§4.4.8,
§4.4.9).

4.7.24. The MethodParameters Attribute

The MethodParameters
attribute is a variable-length attribute in the attributes table of
a method_info structure (§4.6). A
MethodParameters attribute records information about the formal
parameters of a method, such as their names.

There may be at most one
MethodParameters attribute in the attributes table of a
method_info structure.

The value of the
attribute_name_index item must be a valid
index into the constant_pool table. The constant_pool
entry at that index must be a CONSTANT_Utf8_info structure
representing the string "MethodParameters".

attribute_length

The value of
the attribute_length item indicates the
length of the attribute, excluding the initial six
bytes.

parameters_count

The value of
the parameters_count item indicates the
number of parameter descriptors in the method descriptor
(§4.3.3) referenced by
the descriptor_index of the attribute's
enclosing method_info structure.

This is not a constraint which a Java Virtual Machine
implementation must enforce during format checking
(§4.8). The task of matching parameter
descriptors in a method descriptor against the items in
the parameters array below is done by the
reflection libraries of the Java SE platform.

parameters[]

Each entry in the
parameters array contains the following
pair of items:

name_index

The value
of the name_index item must either be
zero or a valid index into the constant_pool
table.

If the value of
the name_index item is zero, then
this parameters element indicates a
formal parameter with no name.

If the value of
the name_index item is nonzero, the
constant_pool entry at that index must be a
CONSTANT_Utf8_info structure representing a valid
unqualified name denoting a formal parameter
(§4.2.2).

access_flags

The value
of the access_flags item is as
follows:

0x0010 (ACC_FINAL)

Indicates that the formal parameter was declared
final.

0x1000 (ACC_SYNTHETIC)

Indicates that the formal parameter was not
explicitly or implicitly declared in source code,
according to the specification of the language in
which the source code was written (JLS
§13.1). (The formal parameter is an implementation
artifact of the compiler which produced this
class file.)

0x8000 (ACC_MANDATED)

Indicates that the formal parameter was implicitly
declared in source code, according to the
specification of the language in which the source
code was written (JLS §13.1). (The formal
parameter is mandated by a language specification,
so all compilers for the language must emit
it.)

The i'th entry in the
parameters array corresponds to the i'th
parameter descriptor in the enclosing method's descriptor. (The
parameters_count item is one byte because a method
descriptor is limited to 255 parameters.) Effectively, this means
the parameters array stores information for all the
parameters of the method. One could imagine other schemes, where
entries in the parameters array specify their
corresponding parameter descriptors, but it would unduly complicate
the MethodParameters attribute.

The i'th entry in
the parameters array may or may not correspond to
the i'th type in the enclosing method's Signature attribute (if
present), or to the i'th annotation in the enclosing method's
parameter annotations.

4.8. Format Checking

When a prospective class
file is loaded by the Java Virtual Machine (§5.3), the Java Virtual Machine
first ensures that the file has the basic format of a class file
(§4.1). This process is known
as format checking. The checks are as
follows:

The first four bytes must contain the right magic number.

All recognized attributes must be of the proper length.

The class file must not be truncated or have extra bytes at
the end.

The constant pool must satisfy the constraints documented
throughout §4.4.

For example, each CONSTANT_Class_info
structure in the constant pool must contain in
its name_index item a valid constant pool
index for a CONSTANT_Utf8_info structure.

All field references and method references in the constant pool
must have valid names, valid classes, and valid descriptors
(§4.3).

Format checking does not ensure that the given field or method
actually exists in the given class, nor that the descriptors
given refer to real classes. Format checking ensures only that
these items are well formed. More detailed checking is performed
when the bytecodes themselves are verified, and during
resolution.

These checks for basic class
file integrity are necessary for any interpretation of the class
file contents. Format checking is distinct from bytecode verification,
although historically they have been confused because both are a form
of integrity check.

4.9. Constraints on Java Virtual Machine Code

The code for a method,
instance initialization method, or class or interface initialization
method (§2.9) is stored in the code array of
the Code attribute of a method_info structure of a class file
(§4.7.3). This section describes the constraints
associated with the contents of the Code_attribute structure.

4.9.1. Static Constraints

The static
constraints on a class file are those defining the
well-formedness of the file. These constraints have been given in the
previous sections, except for static constraints on the code in the
class file. The static constraints on the 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:

Only instances of the instructions documented in
§6.5 may appear in the code
array. Instances of instructions using the reserved opcodes
(§6.2) or any opcodes not documented in
this specification must not appear in the code array.

If the class file version number is 51.0 or above, then
neither the jsr opcode or the jsr_w opcode may appear in the
code array.

The opcode of the first instruction in the code array begins
at index 0.

For each instruction in the code array except the last, the
index of the opcode of the next instruction equals the index of
the opcode of the current instruction plus the length of that
instruction, including all its operands.

The wide instruction is treated like any other instruction for
these purposes; the opcode specifying the operation that a
wide instruction is to modify is treated as one of the
operands of that wide instruction. That opcode must never be
directly reachable by the computation.

The last byte of the last instruction in the code array must
be the byte at index
code_length - 1.

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

The target of a jump or branch instruction must never be the
opcode used to specify the operation to be modified by a wide
instruction; a jump or branch target may be the wide
instruction itself.

Each target, including the default, of each tableswitch
instruction must be the opcode of an instruction within this
method.

Each tableswitch instruction must have a number of entries in
its jump table that is consistent with the value of
its low and
high jump table operands, and
its low value must be less than or equal to
its high value.

No target of a tableswitch instruction may be the opcode used
to specify the operation to be modified by a wide instruction;
a tableswitch target may be a wide instruction
itself.

Each target, including the default, of each lookupswitch
instruction must be the opcode of an instruction within this
method.

Each lookupswitch instruction must have a number
of match-offset pairs that is consistent
with the value of its npairs operand. The
match-offset pairs must be sorted in
increasing numerical order by signed match value.

No target of a lookupswitch instruction may be the opcode used
to specify the operation to be modified by a wide instruction;
a lookupswitch target may be a wide instruction
itself.

The operand of each ldc instruction and each ldc_w
instruction must be a valid index into the constant_pool
table. The constant pool entry referenced by that index must be
of type:

CONSTANT_Integer, CONSTANT_Float, or CONSTANT_String
if the class file version number is less than 49.0.

CONSTANT_Integer, CONSTANT_Float, CONSTANT_String, or
CONSTANT_Class if the class file version number is 49.0
or 50.0.

CONSTANT_Integer, CONSTANT_Float, CONSTANT_String,
CONSTANT_Class, CONSTANT_MethodType, or
CONSTANT_MethodHandle if the class file version number
is 51.0 or above.

The operands of each ldc2_w instruction must represent a valid
index into the constant_pool table. The constant pool entry
referenced by that index must be of type CONSTANT_Long or
CONSTANT_Double.

The subsequent constant pool index must also be a valid index
into the constant pool, and the constant pool entry at that
index must not be used.

The operands of each getfield, putfield, getstatic, and
putstatic instruction must represent a valid index into the
constant_pool table. The constant pool entry referenced by
that index must be of type CONSTANT_Fieldref.

The indexbyte operands of each
invokevirtual instruction must represent a valid index into
the constant_pool table. The constant pool entry referenced by
that index must be of type CONSTANT_Methodref.

The indexbyte operands of each
invokespecial and invokestatic instruction must represent a
valid index into the constant_pool table. If the class file
version number is less than 52.0, the constant pool entry
referenced by that index must be of type CONSTANT_Methodref;
if the class file version number is 52.0 or above, the
constant pool entry referenced by that index must be of type
CONSTANT_Methodref or CONSTANT_InterfaceMethodref.

The indexbyte operands of each
invokeinterface instruction must represent a valid index into
the constant_pool table. The constant pool entry referenced by
that index must be of type CONSTANT_InterfaceMethodref.

The value of the count operand of each
invokeinterface instruction must reflect the number of local
variables necessary to store the arguments to be passed to the
interface method, as implied by the descriptor of the
CONSTANT_NameAndType_info structure referenced by the
CONSTANT_InterfaceMethodref constant pool entry.

The fourth operand byte of each invokeinterface instruction
must have the value zero.

The indexbyte operands of each
invokedynamic instruction must represent a valid index into
the constant_pool table. The constant pool entry referenced by
that index must be of type CONSTANT_InvokeDynamic.

The third and fourth operand bytes of each invokedynamic
instruction must have the value zero.

Only the invokespecial instruction is allowed to invoke an
instance initialization method
(§2.9).

No other method whose name begins with the character '<'
('\u003c') may be called by the method
invocation instructions. In particular, the class or interface
initialization method specially named <clinit> is never called
explicitly from Java Virtual Machine instructions, but only implicitly by the
Java Virtual Machine itself.

The operands of each instanceof, checkcast, new, and
anewarray instruction, and the indexbyte
operands of each multianewarray instruction, must represent a
valid index into the constant_pool table. The constant pool
entry referenced by that index must be of type
CONSTANT_Class.

No new instruction may reference a constant pool entry of type
CONSTANT_Class that represents an array type
(§4.3.2). The new instruction cannot be
used to create an array.

No anewarray instruction may be used to create an array of
more than 255 dimensions.

A multianewarray instruction must be used only to create an
array of a type that has at least as many dimensions as the
value of its dimensions operand. That is,
while a multianewarray instruction is not required to create
all of the dimensions of the array type referenced by
its indexbyte operands, it must not attempt
to create more dimensions than are in the array type.

The dimensions operand of each
multianewarray instruction must not be zero.

The atype operand of each newarray
instruction must take one of the values T_BOOLEAN (4),
T_CHAR (5), T_FLOAT (6), T_DOUBLE (7), T_BYTE (8),
T_SHORT (9), T_INT (10), or T_LONG (11).

The index operand of each iload, fload,
aload, istore, fstore, astore, iinc, and ret
instruction must be a non-negative integer no greater
than max_locals - 1.

The implicit index of each iload_<n>, fload_<n>, aload_<n>,
istore_<n>, fstore_<n>, and astore_<n> instruction must be no
greater than max_locals - 1.

The index operand of each lload, dload,
lstore, and dstore instruction must be no greater
than max_locals - 2.

The implicit index of each lload_<n>, dload_<n>, lstore_<n>, and
dstore_<n> instruction must be no greater
than max_locals - 2.

The indexbyte operands of each wide
instruction modifying an iload, fload, aload, istore,
fstore, astore, iinc, or ret instruction must represent
a non-negative integer no greater than
max_locals - 1.

The indexbyte operands of each wide
instruction modifying an lload, dload, lstore, or dstore
instruction must represent a non-negative integer no greater
than max_locals - 2.

4.9.2. Structural Constraints

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

Each instruction must only be executed with the appropriate type
and number of arguments in the operand stack and local variable
array, regardless of the execution path that leads to its
invocation.

An instruction operating on values of type int is also
permitted to operate on values of type boolean, byte,
char, and short.

As noted in §2.3.4 and
§2.11.1, the Java Virtual Machine internally converts
values of types boolean, byte, short, and char to type
int.)

If an instruction can be executed along several different
execution paths, the operand stack must have the same depth
(§2.6.2) prior to the execution of the
instruction, regardless of the path taken.

At no point during execution can the operand stack grow to a
depth greater than that implied by
the max_stack item.

At no point during execution can more values be popped from the
operand stack than it contains.

At no point during execution can the order of the local variable
pair holding a value of type long or double be reversed or
the pair split up. At no point can the local variables of such a
pair be operated on individually.

No local variable (or local variable pair, in the case of a
value of type long or double) can be accessed before it is
assigned a value.

Each invokespecial instruction must name an instance
initialization method (§2.9), a method in
the current class or interface, a method in a superclass of the
current class, a method in a direct superinterface of the
current class or interface, or a method in Object.

When an instance initialization method is invoked, an
uninitialized class instance must be in an appropriate position
on the operand stack. An instance initialization method must
never be invoked on an initialized class instance.

If an invokespecial instruction names an instance
initialization method and the target reference on the operand
stack is an uninitialized class instance for the current class,
then invokespecial must name an instance initialization method
from the current class or its direct superclass.

If an invokespecial instruction names an instance
initialization method and the target reference on the
operand stack is a class instance created by an earlier new
instruction, then invokespecial must name an instance
initialization method from the class of that class
instance.

If an invokespecial instruction names a method which is not an
instance initialization method, then the type of the target
reference on the operand stack must be assignment compatible
with the current class (JLS §5.2).

Each instance initialization method, except for the instance
initialization method derived from the constructor of class
Object, must call either another instance initialization
method of this or an instance initialization method of its
direct superclass super before its instance members
are accessed.

However, instance fields of this that are declared in the
current class may be assigned before
calling any instance initialization method.

When any instance method is invoked or when any instance
variable is accessed, the class instance that contains the
instance method or instance variable must already be
initialized.

If there is an uninitialized class instance in a local variable
in code protected by an exception handler, then i) if the
handler is inside an <init> method, the handler must throw an
exception or loop forever, and ii) if the handler is not inside
an <init> method, the uninitialized class instance must remain
uninitialized.

There must never be an uninitialized class instance on the
operand stack or in a local variable when a jsr or jsr_w
instruction is executed.

The type of every class instance that is the target of a method
invocation instruction must be assignment compatible with the
class or interface type specified in the instruction (JLS
§5.2).

The types of the arguments to each method invocation must be
method invocation compatible with the method descriptor (JLS
§5.3, §4.3.3).

Each return instruction must match its method's return
type:

If the method returns a boolean, byte, char, short,
or int, only the ireturn instruction may be used.

If the method returns a float, long, or double, only
an freturn, lreturn, or dreturn instruction,
respectively, may be used.

If the method returns a reference type, only an areturn
instruction may be used, and the type of the returned value
must be assignment compatible with the return descriptor of
the method (JLS §5.2, §4.3.3).

All instance initialization methods, class or interface
initialization methods, and methods declared to return
void must use only the return instruction.

The type of every class instance accessed by a getfield
instruction or modified by a putfield instruction must be
assignment compatible with the class type specified in the
instruction (JLS §5.2).

The type of every value stored by a putfield or putstatic
instruction must be compatible with the descriptor of the field
(§4.3.2) of the class instance or class
being stored into:

If the descriptor type is boolean, byte, char,
short, or int, then the value must be an int.

If the descriptor type is float, long, or double, then
the value must be a float, long, or double,
respectively.

If the descriptor type is a reference type, then the value must
be of a type that is assignment compatible with the
descriptor type (JLS §5.2).

The type of every value stored into an array by an aastore
instruction must be a reference type.

The component type of the array being stored into by the
aastore instruction must also be a reference type.

Each athrow instruction must throw only values that are
instances of class Throwable or of subclasses of
Throwable.

Each class mentioned in a catch_type item of
the exception_table array of the method's
Code_attribute structure must be Throwable or a subclass of
Throwable.

If getfield or putfield is used to access a protected
field declared in a superclass that is a member of a different
run-time package than the current class, then the type of the
class instance being accessed must be the same as or a subclass
of the current class.

If invokevirtual or invokespecial is used to access a
protected method declared in a superclass that is a member of
a different run-time package than the current class, then the
type of the class instance being accessed must be the same as or
a subclass of the current class.

Execution never falls off the bottom of the code array.

No return address (a value of type returnAddress) may be
loaded from a local variable.

The instruction following each jsr or jsr_w instruction may
be returned to only by a single ret instruction.

No jsr or jsr_w instruction that is returned to may be used
to recursively call a subroutine if that subroutine is already
present in the subroutine call chain. (Subroutines can be nested
when using try-finally constructs from within a finally
clause.)

Each instance of type returnAddress can be returned to at most
once.

If a ret instruction returns to a point in the subroutine call
chain above the ret instruction corresponding to a given
instance of type returnAddress, then that instance can never
be used as a return address.

4.10. Verification of class Files

Even though a compiler for
the Java programming language must only produce class files that satisfy all the
static and structural constraints in the previous sections, the Java Virtual Machine
has no guarantee that any file it is asked to load was generated by
that compiler or is properly formed. Applications such as web browsers
do not download source code, which they then compile; these
applications download already-compiled class files. The browser
needs to determine whether the class file was produced by a
trustworthy compiler or by an adversary attempting to exploit the
Java Virtual Machine.

An additional problem with compile-time checking is
version skew. A user may have successfully compiled a class,
say PurchaseStockOptions, to be a subclass
of TradingClass. But the definition of
TradingClass might have changed since the time the
class was compiled in a way that is not compatible with pre-existing
binaries. Methods might have been deleted or had their return types or
modifiers changed. Fields might have changed types or changed from
instance variables to class variables. The access modifiers of a
method or variable may have changed from public to private. For a
discussion of these issues, see Chapter 13, "Binary Compatibility," in
The Java Language Specification, Java SE 8 Edition.

Because of these potential
problems, the Java Virtual Machine needs to verify for itself that the desired
constraints are satisfied by the class files it attempts to
incorporate. A Java Virtual Machine implementation verifies that each class file
satisfies the necessary constraints at linking time
(§5.4).

Link-time verification
enhances the performance of the run-time interpreter. Expensive checks
that would otherwise have to be performed to verify constraints at run
time for each interpreted instruction can be eliminated. The Java Virtual Machine can
assume that these checks have already been performed. For example, the
Java Virtual Machine will already know the following:

There are no operand
stack overflows or underflows.

All local variable uses
and stores are valid.

The arguments to all
the Java Virtual Machine instructions are of valid types.

There are two strategies that
Java Virtual Machine implementations may use for verification:

Verification by type
checking must be used to verify class files whose version
number is greater than or equal to 50.0.

Verification by type
inference must be supported by all Java Virtual Machine implementations, except
those conforming to the Java ME CLDC and Java Card profiles, in
order to verify class files whose version number is less than
50.0.

In both strategies, verification is
mainly concerned with enforcing the static and structural constraints
from §4.9 on the code array of the Code
attribute (§4.7.3). However, there are three
additional checks outside the Code attribute which must be performed
during verification:

4.10.1. Verification by Type Checking

A class file whose
version number is 50.0 or above (§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.

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:

Fourth, we specify
how a method is type checked, for methods without code
(§4.10.1.5) and methods with code
(§4.10.1.6).

Fifth, we discuss
type checking issues common to all load and store instructions
(§4.10.1.7), and also issues of access to
protected members (§4.10.1.8).

Finally, we specify
the rules to type check each instruction
(§4.10.1.9).

4.10.1.1. Accessors for Java Virtual Machine Artifacts

We stipulate the
existence of 28 Prolog predicates ("accessors") that have certain
expected behavior but whose formal definitions are not given in this
specification.

classClassName(Class, ClassName)

Extracts the name, ClassName, of the
class Class.

classIsInterface(Class)

True iff the class, Class, is an
interface.

classIsNotFinal(Class)

True iff the class, Class, is not a final
class.

classSuperClassName(Class, SuperClassName)

Extracts the name, SuperClassName, of the
superclass of class Class.

classInterfaces(Class, Interfaces)

Extracts a list, Interfaces, of the direct
superinterfaces of the class Class.

classMethods(Class, Methods)

Extracts a list, Methods, of the methods
declared in the class Class.

classAttributes(Class, Attributes)

Extracts a list, Attributes, of the
attributes of the class Class.

Each attribute is represented as a functor application of the
form attribute(AttributeName, AttributeContents),
where AttributeName is the name of the
attribute. The format of the attribute's contents is
unspecified.

classDefiningLoader(Class, Loader)

Extracts the defining class loader, Loader,
of the class Class.

isBootstrapLoader(Loader)

True iff the class loader Loader is the
bootstrap class loader.

loadedClass(Name, InitiatingLoader, ClassDefinition)

True iff there exists a class named Name
whose representation (in accordance with this specification)
when loaded by the class
loader InitiatingLoader
is ClassDefinition.

methodName(Method, Name)

Extracts the name, Name, of the
method Method.

methodAccessFlags(Method, AccessFlags)

Extracts the access flags, AccessFlags, of
the method Method.

methodDescriptor(Method, Descriptor)

Extracts the descriptor, Descriptor, of the
method Method.

methodAttributes(Method, Attributes)

Extracts a list, Attributes, of the
attributes of the method Method.

isInit(Method)

True iff Method (regardless of class) is <init>.

isNotInit(Method)

True iff Method (regardless of class) is not <init>.

isNotFinal(Method, Class)

True iff Method in
class Class is not final.

isStatic(Method, Class)

True iff Method in
class Class is static.

isNotStatic(Method, Class)

True iff Method in
class Class is not static.

isPrivate(Method, Class)

True iff Method in
class Class is private.

isNotPrivate(Method, Class)

True iff Method in
class Class is not private.

isProtected(MemberClass, MemberName, MemberDescriptor)

True iff there is a member named MemberName
with descriptor MemberDescriptor in the
class MemberClass and it is
protected.

isNotProtected(MemberClass, MemberName, MemberDescriptor)

True iff there is a member named MemberName
with descriptor MemberDescriptor in the
class MemberClass and it is not
protected.

parseFieldDescriptor(Descriptor, Type)

Converts a field descriptor, Descriptor,
into the corresponding verification type Type
(§4.10.1.2).

parseMethodDescriptor(Descriptor, ArgTypeList, ReturnType)

Converts a method descriptor, Descriptor,
into a list of verification
types, ArgTypeList, corresponding to the
method argument types, and a verification
type, ReturnType, corresponding to the
return type.

Extracts the instruction
stream, ParsedCode, of the method
Method in Class, as well
as the maximum operand stack
size, MaxStack, the maximal number of local
variables, FrameSize, the exception
handlers, Handlers, and the stack
map StackMap.

The representation of the instruction stream and stack map
attribute must be as specified in
§4.10.1.3 and
§4.10.1.4.

samePackageName(Class1, Class2)

True iff the package names of Class1
and Class2 are the same.

differentPackageName(Class1, Class2)

True iff the package names of Class1
and Class2 are different.

When type checking a
method's body, it is convenient to access information about the
method. For this purpose, we define
an environment, a six-tuple consisting of:

The principle guiding the determination as to which
accessors are stipulated and which are fully specified is that we do
not want to over-specify the representation of the class
file. Providing specific accessors to the Class
or Method term would force us to completely specify
the format for a Prolog term representing the class file.

4.10.1.2. Verification Type System

The type checker enforces
a type system based upon a hierarchy of verification
types, illustrated below.

Class and interface
types correspond to verification types that use the
functor class. The verification type
class(N, L)
represents the class whose binary name
is N as loaded by the
loader L. Note
that L is an initiating
loader (§5.3) of the class represented
by class(N, L)
and may, or may not, be the class's defining loader.

For example, the class type Object would be
represented as class('java/lang/Object', BL),
where BL is the bootstrap loader.

These subtype rules are not necessarily the most
obvious formulation of subtyping. There is a clear split between
subtyping rules for reference types in the Java programming language, and rules for
the remaining verification types. The split allows us to state general
subtyping relations between Java programming language reference types and other
verification types. These relations hold independently of a Java
reference type's position in the type hierarchy, and help to prevent
excessive class loading by a Java Virtual Machine implementation. For example, we do
not want to start climbing the Java superclass hierarchy in response
to a query of the form class(foo, L) <:
twoWord.

We also have a rule that says subtyping is
reflexive, so together these rules cover most verification types that
are not reference types in the Java programming language.

Subtype rules for the reference types in the
Java programming language are specified recursively with
isJavaAssignable.

4.10.1.3. Instruction Representation

Individual bytecode
instructions are represented in Prolog as terms whose functor is the
name of the instruction and whose arguments are its parsed
operands.

For example, an aload instruction is represented
as the term aload(N), which includes the
index N that is the operand of the
instruction.

The instructions as a
whole are represented as a list of terms of the form:

instruction(Offset, AnInstruction)

For example, instruction(21,
aload(1)).

The order of instructions
in this list must be the same as in the class file.

A few instructions have
operands that are constant pool entries representing fields, methods,
and dynamic call sites. In the constant pool, a field is represented
by a CONSTANT_Fieldref_info structure, a method is represented by a
CONSTANT_InterfaceMethodref_info structure (for an interface's
method) or a CONSTANT_Methodref_info structure (for a class's
method), and a dynamic call site is represented by a
CONSTANT_InvokeDynamic_info structure (§4.4.2,
§4.4.10). Such structures are represented as
functor applications of the form:

field(FieldClassName, FieldName,
FieldDescriptor) for a field, where
FieldClassName is the name of the class
referenced by the class_index item in the
CONSTANT_Fieldref_info structure,
and FieldName
and FieldDescriptor correspond to the name
and field descriptor referenced by
the name_and_type_index item of the
CONSTANT_Fieldref_info structure.

imethod(MethodIntfName, MethodName,
MethodDescriptor) for an interface's method,
where MethodIntfName is the name of the
interface referenced by the class_index item
of the CONSTANT_InterfaceMethodref_info structure,
and MethodName
and MethodDescriptor correspond to the name
and method descriptor referenced by
the name_and_type_index item of the
CONSTANT_InterfaceMethodref_info structure;

method(MethodClassName, MethodName,
MethodDescriptor) for a class's method,
where MethodClassName is the name of the
class referenced by the class_index item of
the CONSTANT_Methodref_info structure,
and MethodName and
MethodDescriptor correspond to the name and
method descriptor referenced by
the name_and_type_index item of the
CONSTANT_Methodref_info structure; and

dmethod(CallSiteName, MethodDescriptor) for a
dynamic call site, where
CallSiteName
and MethodDescriptor correspond to the name
and method descriptor referenced by
the name_and_type_index item of the
CONSTANT_InvokeDynamic_info structure.

For clarity, we assume
that field and method descriptors (§4.3.2,
§4.3.3) are mapped into more readable names: the
leading L and trailing ; are dropped from class names,
and the BaseType characters used for primitive
types are mapped to the names of those types.

For example, a getfield instruction whose operand
was an index into the constant pool that refers to a
field foo of type F in
class Bar would be represented
as getfield(field('Bar', 'foo', 'F')).

For example, an ldc instruction for loading the
integer 91 would be encoded as ldc(int(91)).

4.10.1.4. Stack Map Frame Representation

Stack map frames are
represented in Prolog as a list of terms of the form:

stackMap(Offset, TypeState)

where:

Offset is an integer indicating
the bytecode offset at which the stack map frame applies
(§4.7.4).

The order of bytecode offsets in this list
must be the same as in the class file.

TypeState is the expected incoming type state
for the instruction at Offset.

A type
state is a mapping from locations in the operand stack and
local variables of a method to verification types. It has the
form:

frame(Locals, OperandStack, Flags)

where:

Locals is a list of verification types, such
that the i'th element of the list (with 0-based indexing)
represents the type of local variable i.

OperandStack is a list of verification types,
such that the first element of the list represents the type of
the top of the operand stack, and the types of stack entries
below the top follow in the list in the appropriate
order.

Types of size 2 (long and double) are represented by two
stack entries, with the first entry being top and the second
entry being the type itself.

For example, a stack with a double value, an
int value, and a long value is represented in a type state
as a stack with five entries: top and double entries for the
double value, an int entry for the int value, and top
and long entries for the long
value. Accordingly, OperandStack is the
list [top, double, int, top, long].

Flags is a list which may either be empty or
have the single element flagThisUninit.

If any local variable in Locals has the type
uninitializedThis, then Flags has the
single element flagThisUninit,
otherwise Flags is an empty list.

flagThisUninit is used in constructors to mark
type states where initialization of this has not yet been
completed. In such type states, it is illegal to return from the
method.

Subtyping of verification
types is extended pointwise to type states.

The local variable array
of a method has a fixed length by construction
(see methodInitialStackFrame in
§4.10.1.6) while the operand stack grows and
shrinks. Therefore, we require an explicit check on the length of the
operand stacks whose assignability is desired.

Certain array
instructions (§aaload,
§arraylength,
§baload,
§bastore) peek at the types of values
on the operand stack in order to check they are array types. The
following clause accesses the i'th element of the operand stack
from a type state.

Manipulation of the operand stack by load and store instructions
(§4.10.1.7) is complicated by the fact that some
types occupy two entries on the stack. The predicates given below take
this into account, allowing the rest of the specification to abstract
from this issue.

Pop an individual type off the stack. More
precisely, if the logical top of the stack is some subtype of the
specified type, Type, then pop it. If a type occupies two stack
entries, then the logical top of the stack is really the type just
below the top, and the top of the stack is the unusable type
top.

Push a logical type onto the stack. The exact
behavior varies with the size of the type. If the pushed type is of
size 1, we just push it onto the stack. If the pushed type is of size
2, we push it, and then push top.

Manipulation of the
operand stack by the dup instructions is specified entirely in terms
of the category of types for values on the stack
(§2.11.1).

Category 1 types occupy a single stack
entry. Popping a logical type of category 1, Type, off the stack is
possible if the top of the stack is Type and Type is not top
(otherwise it could denote the upper half of a category 2 type). The
result is the incoming stack, with the top entry popped off.

Category 2 types occupy two stack entries. Popping a
logical type of category 2, Type, off the stack is possible if the
top of the stack is type top, and the entry directly below it is
Type. The result is the incoming stack, with the top two entries
popped off.

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

Most of the type rules
for individual instructions (§4.10.1.9) depend
on the notion of a valid type transition. A type
transition is valid if one can pop a list of
expected types off the incoming type state's operand stack and replace
them with an expected result type, resulting in a new valid type
state. In particular, the size of the operand stack in the new type
state must not exceed its maximum declared size.

final methods that are private
and/or static are unusual, as private methods and static methods
cannot be overridden per se. Therefore, if a finalprivate method
or a finalstatic method is found, it was logically not overridden
by another method.

A method with code is type safe if it is possible to
merge the code and the stack map frames into a single stream such that
each stack map frame precedes the instruction it corresponds to, and
the merged stream is type correct. The method's exception
handlers, if any, must also be legal.

An exception handler is represented by a functor
application of the form:

handler(Start, End, Target, ClassName)

whose arguments are, respectively, the start and end
of the range of instructions covered by the handler, the first
instruction of the handler code, and the name of the exception class
that this handler is designed to handle.

An exception handler is legal
if its start (Start) is less than its end
(End), there exists an instruction whose offset is
equal to Start, there exists an instruction whose
offset equals End, and the handler's exception
class is assignable to the class Throwable. The exception class of a
handler is Throwable if the handler's class entry is 0, otherwise it
is the class named in the handler.

An additional requirement exists for a handler inside an <init> method
if one of the instructions covered by the handler is invokespecial
of an <init> method. In this case, the fact that a handler is running
means the object under construction is likely broken, so it is
important that the handler does not swallow the exception and allow
the enclosing <init> method to return normally to the
caller. Accordingly, the handler is required to either complete
abruptly by throwing an exception to the caller of the enclosing
<init> method, or to loop forever.

Merging instructions and stack map frames into a
single stream involves four cases:

Merging an empty StackMap and
a list of instructions yields the original list of
instructions.

mergeStackMapAndCode([], CodeList, CodeList).

Given a list of stack map frames beginning with
the type state for the instruction at Offset,
and a list of instructions beginning
at Offset, the merged list is the head of the
stack map frame list, followed by the head of the instruction
list, followed by the merge of the tails of the two
lists.

Otherwise, given a list of stack map frames
beginning with the type state for the instruction
at OffsetM, and a list of instructions
beginning at OffsetP, then,
if OffsetP < OffsetM, the merged list
consists of the head of the instruction list, followed by the
merge of the stack map frame list and the tail of the
instruction list.

Otherwise, the merge of the two lists is
undefined. Since the instruction list has monotonically
increasing offsets, the merge of the two lists is not defined
unless every stack map frame offset has a corresponding
instruction offset and the stack map frames are in monotonically
increasing order.

To determine if the merged stream for a method is
type correct, we first infer the method's initial type state.

The initial type state of a method consists of an
empty operand stack and local variable types derived from the type of
this and the arguments, as well as the appropriate flag, depending
on whether this is an <init> method.

Given a list of types, the following clause produces
a list where every type of size 2 has been substituted by two entries:
one for itself, and one top entry. The result then corresponds to
the representation of the list as 32-bit words in the Java Virtual Machine.

For the initial type state of an instance method, we
compute the type of this and put it in a list. The type of this in
the <init> method of Object is Object; in other <init> methods,
the type of this is uninitializedThis; otherwise, the type of
this in an instance method is class(N, L)
where N is the name of the class containing the
method and L is its defining class loader.

For the initial type state of a static method,
this is irrelevant, so the list is empty.

We now compute whether the merged stream for a
method is type correct, using the method's initial type state:

If we have a stack map frame and an incoming
type state, the type state must be assignable to the one in the
stack map frame. We may then proceed to type check the rest of
the stream with the type state given in the stack map
frame.

A merged code stream is type safe relative to an
incoming type state T if it begins with an
instruction I that is type safe relative
to T,
and Isatisfies its
exception handlers (see below), and the tail of the stream is
type safe given the type state following that execution
of I.

NextStackFrame indicates what
falls through to the following instruction. For an unconditional
branch instruction, it will have the special value
afterGoto. ExceptionStackFrame indicates
what is passed to exception handlers.

After an unconditional branch (indicated by an
incoming type state of afterGoto), if we have a stack map
frame giving the type state for the following instructions, we
can proceed and type check them using the type state provided by
the stack map frame.

An instruction satisfies an
exception handler if the instructions's outgoing type state
is ExcStackFrame, and the handler's target (the
initial instruction of the handler code) is type safe assuming an
incoming type state T. The type
state T is derived
from ExcStackFrame by replacing the operand stack
with a stack whose sole element is the handler's exception
class.

4.10.1.7. Type Checking Load and Store Instructions

All load instructions are
variations on a common pattern, varying the type of the value that the
instruction loads.

Loading a value of type
Type from local variable Index is type safe, if
the type of that local variable
is ActualType, ActualType is
assignable to Type, and pushing ActualType onto
the incoming operand stack is a valid type transition
(§4.10.1.4) that yields a new type
state NextStackFrame. After execution of the load
instruction, the type state will
be NextStackFrame.

All store instructions
are variations on a common pattern, varying the type of the value that
the instruction stores.

In general, a store
instruction is type safe if the local variable it references is of a
type that is a supertype of Type, and the top of the operand stack
is of a subtype of Type, where Type is the type the instruction is
designed to store.

More precisely, the store
is type safe if one can pop a type ActualType that
"matches" Type (that is, is a subtype of Type) off the operand
stack (§4.10.1.4), and then legally assign that
type the local
variable LIndex.

Given local variables Locals,
modifying Index to have type Type results in the
local variable list NewLocals. The modifications
are somewhat involved, because some values (and their corresponding
types) occupy two local variables. Hence,
modifying LN may require
modifying LN+1 (because the
type will occupy both the N
and N+1 slots)
or LN-1 (because
local N used to be the upper half of the two word
value/type starting at local N-1, and so
local N-1 must be invalidated), or both. This is
described further below. We start
at L0 and count up.

Given LocalsRest, the suffix of
the local variable list starting at index I,
modifying local variable Index to have type Type
results in the local variable list
suffix NextLocalsRest.

If I < Index-1, just copy the
input to the output and recurse forward. If I =
Index-1, the type of local I may
change. This can occur if LI
has a type of size 2. Once we
set LI+1 to the new type
(and the corresponding value), the type/value
of LI will be invalidated,
as its upper half will be trashed. Then we recurse forward.

When we find the variable, and it only occupies one
word, we change it to Type and we're done. When we find the
variable, and it occupies two words, we change its type to Type and
the next word to top.

We refer to a local whose index immediately precedes
a local whose type will be modified as a pre-index
variable. The future type of a pre-index variable of type
InputType is Result. If the
type, Type, of the pre-index local is of size 1, it
doesn't change. If the type of the pre-index
local, Type, is 2, we need to mark the lower half
of its two word value as unusable, by setting its type
to top.

4.10.1.8. Type Checking for protected Members

All instructions that
access members must contend with the rules concerning protected
members. This section describes the protected check that corresponds
to JLS §6.6.2.1.

The protected check applies only to protected
members of superclasses of the current class.
protected members in other classes will be caught by the access
checking done at resolution (§5.4.4). There are
four cases:

If the name of a class is not the name of any superclass, it
cannot be a superclass, and so it can safely be ignored.

If the MemberClassName is the same as the
name of a superclass, the class being resolved may indeed be a
superclass. In this case, if no superclass
named MemberClassName in a different run-time
package has a protected member
named MemberName with
descriptor MemberDescriptor, the protected
check does not apply.

This is because the actual class being resolved
will either be one of these superclasses, in which case we know
that it is either in the same run-time package, and the access
is legal; or the member in question is not protected and the
check does not apply; or it will be a subclass, in which case
the check would succeed anyway; or it will be some other class
in the same run-time package, in which case the access is legal
and the check need not take place; or the verifier need not flag
this as a problem, since it will be caught anyway because
resolution will per force fail.

If there does exist a protected superclass member in a
different run-time package, then
load MemberClassName; if the member in
question is not protected, the check does not apply. (Using a
superclass member that is not protected is trivially
correct.)

The predicate classesInOtherPkgWithProtectedMember(Class,
MemberName, MemberDescriptor, MemberClassName, Chain, List)
is true if List is the set of classes
in Chain with name
MemberClassName that are in a different run-time
package than Class which have a protected member
named MemberName with descriptor
MemberDescriptor.

4.10.1.9. Type Checking Instructions

In general, the type rule
for an instruction is given relative to an
environment Environment that defines the class and
method in which the instruction occurs
(§4.10.1.1), and the
offset Offset within the method at which the
instruction occurs. The rule states that if the incoming type
state StackFrame fulfills certain requirements,
then:

The instruction is type safe.

It is provable that the type state after the instruction
completes normally has a particular form given
by NextStackFrame, and that the type state
after the instruction completes abruptly is given
by ExceptionStackFrame.

The type state after an instruction completes abruptly is the
same as the incoming type state, except that the operand stack
is empty.

Many instructions have
type rules that are completely isomorphic to the rules for other
instructions. If an instruction b1 is isomorphic to
another instruction b2, then the type rule
for b1 is the same as the type rule
for b2.

The English language
description of each rule is intended to be readable, intuitive, and
concise. As such, the description avoids repeating all the contextual
assumptions given above. In particular:

The description does not explicitly mention the environment.

When the description speaks of the operand stack or local
variables in the following, it is referring to the operand stack
and local variable components of a type state: either the
incoming type state or the outgoing one.

The type state after the instruction completes abruptly is
almost always identical to the incoming type state. The
description only discusses the type state after the instruction
completes abruptly when that is not the case.

The description speaks of popping and pushing types onto the
operand stack, and does not explicitly discuss issues of stack
underflow or overflow. The description assumes these operations
can be completed successfully, but the Prolog clauses for
operand stack manipulation ensure that the necessary checks are
made.

The description discusses only the manipulation of logical
types. In practice, some types take more than one word. The
description abstracts from these representation details, but the
Prolog clauses that manipulate data do not.

Any ambiguities can be
resolved by referring to the formal Prolog clauses.

aaload

An aaload instruction is type safe iff one can validly replace types
matching int and an array type with component
type ComponentType
where ComponentType is a subtype of Object,
with ComponentType yielding the outgoing type
state.

aload, aload_<n>

An aload instruction with operand Index is type
safe and yields an outgoing type
state NextStackFrame, if a load instruction with
operand Index and type reference is type safe and
yields an outgoing type state NextStackFrame.

anewarray

An anewarray instruction with operand CP is type safe iff CP
refers to a constant pool entry denoting either a class type or an
array type, and one can legally replace a type matching int on the
incoming operand stack with an array with component type CP yielding
the outgoing type state.

areturn

An areturn instruction is type safe iff the enclosing method has a
declared return type, ReturnType, that is a reference
type, and one can validly pop a type
matching ReturnType off the incoming operand
stack.

astore, astore_<n>

An astore instruction with operand Index is type
safe and yields an outgoing type
state NextStackFrame, if a store instruction with
operand Index and type reference is type safe and
yields an outgoing type
state NextStackFrame.

checkcast

A checkcast instruction with operand CP is type safe iff CP
refers to a constant pool entry denoting either a class or an array,
and one can validly replace the type Object on top of the incoming
operand stack with the type denoted by CP yielding the outgoing type
state.

ddiv

dload, dload_<n>

A dload instruction with operand Index is type
safe and yields an outgoing type
state NextStackFrame, if a load instruction with
operand Index and type double is type safe and
yields an outgoing type state NextStackFrame.

dstore, dstore_<n>

A dstore instruction with operand Index is type
safe and yields an outgoing type
state NextStackFrame, if a store instruction with
operand Index and type double is type safe and
yields an outgoing type state NextStackFrame.

dup_x1

A dup_x1 instruction is type safe iff one can validly replace two
category 1 types, Type1, and Type2, on the incoming operand stack
with the types Type1, Type2, Type1, yielding the outgoing type
state.

A dup_x2 instruction is a type safe form 2dup_x2 instruction iff one can validly replace a category 1 type,
Type1, and a category 2 type, Type2, on the incoming operand stack
with the types Type1, Type2, Type1, yielding the outgoing type
state.

A dup2 instruction is a type safe form 1dup2
instruction iff one can validly replace two category 1 types, Type1
and Type2 on the incoming operand stack with the types Type1,
Type2, Type1, Type2, yielding the outgoing type state.

A dup2_x1 instruction is a type safe form 2dup2_x1 instruction iff one can validly replace a category 2 type,
Type1, and a category 1 type, Type2, on the incoming operand stack
with the types Type1, Type2, Type1, yielding the outgoing type
state.

A dup2_x2 instruction is a type safe form 4dup2_x2 instruction iff one can validly replace two category 2
types, Type1, Type2, on the incoming operand stack with the types
Type1, Type2, Type1, yielding the outgoing type state.

fdiv

fload, fload_<n>

An fload instruction with operand Index is type
safe and yields an outgoing type
state NextStackFrame, if a load instruction with
operand Index and type float is type safe and
yields an outgoing type state NextStackFrame.

fstore, fstore_<n>

An fstore instruction with operand Index is type
safe and yields an outgoing type
state NextStackFrame, if a store instruction with
operand Index and type float is type safe and
yields an outgoing type
state NextStackFrame.

fsub

getfield

A getfield instruction with operand CP is type safe iff CP
refers to a constant pool entry denoting a field whose declared type
is FieldType, declared in a
class FieldClass, and one can validly replace a
type matching FieldClass with
type FieldType on the incoming operand stack
yielding the outgoing type state. FieldClass must
not be an array type. protected fields are subject to additional
checks (§4.10.1.8).

getstatic

A getstatic instruction with operand CP is type safe iff CP
refers to a constant pool entry denoting a field whose declared type
is FieldType, and one can validly
push FieldType on the incoming operand stack
yielding the outgoing type state.

if_acmp<cond>

An if_acmpeq instruction is type safe iff one can validly pop types
matching reference and reference on the incoming operand stack yielding the
outgoing type state NextStackFrame, and the operand
of the instruction, Target, is a valid branch
target assuming an incoming type state
of NextStackFrame.

if_icmp<cond>

An if_icmpeq instruction is type safe iff one can validly pop types
matching int and int on the incoming operand stack yielding the
outgoing type state NextStackFrame, and the operand
of the instruction, Target, is a valid branch
target assuming an incoming type state
of NextStackFrame.

if<cond>

An ifeq instruction is type safe iff one can validly pop a type
matching int off the incoming operand stack yielding the outgoing
type state NextStackFrame, and the operand of the
instruction, Target, is a valid branch target
assuming an incoming type state
of NextStackFrame.

ifnonnull

An ifnonnull instruction is type safe iff one can validly pop a type
matching reference off the incoming operand stack yielding the outgoing
type state NextStackFrame, and the operand of the
instruction, Target, is a valid branch target
assuming an incoming type state of NextStackFrame.

iload, iload_<n>

An iload instruction with operand Index is type
safe and yields an outgoing type
state NextStackFrame, if a load instruction with
operand Index and type int is type safe and
yields an outgoing type state NextStackFrame.

instanceof

An instanceof instruction with operand CP is type safe iff CP
refers to a constant pool entry denoting either a class or an array,
and one can validly replace the type Object on top of the incoming
operand stack with type int yielding the outgoing type state.

invokeinterface

An invokeinterface instruction is type safe iff all of the following
are true:

Its first operand, CP, refers to a constant pool entry
denoting an interface method named MethodName
with descriptor Descriptor that is a member
of an interface MethodIntfName.

MethodName is not <init>.

MethodName is not <clinit>.

Its second operand, Count, is a valid count
operand (see below).

One can validly replace types matching the
type MethodIntfName and the argument types
given in Descriptor on the incoming operand
stack with the return type given
in Descriptor, yielding the outgoing type
state.

invokespecial

An invokespecial instruction is type safe iff all of the following
are true:

Its first operand, CP, refers to a constant pool entry
denoting a method named MethodName with
descriptor Descriptor that is a member of a
class MethodClassName.

Either:

MethodName is not <init>.

MethodName is not <clinit>.

One can validly replace types matching the current class and
the argument types given in Descriptor on
the incoming operand stack with the return type given
in Descriptor, yielding the outgoing type
state.

One can validly replace types matching the
class MethodClassName and the argument
types given in Descriptor on the incoming
operand stack with the return type given
in Descriptor.

One can validly pop types matching the argument types given
in Descriptor and an uninitialized
type, UninitializedArg, off the incoming
operand stack,
yielding OperandStack.

The outgoing type state is derived from the incoming type
state by first replacing the incoming operand stack
with OperandStack and then replacing all
instances of UninitializedArg with the
type of instance being initialized.

To compute what type the uninitialized argument's type needs to be
rewritten to, there are two cases:

If we are initializing an object within its constructor, its
type is initially uninitializedThis. This type will be
rewritten to the type of the class of the <init> method.

The second case arises from initialization of an object created
by new. The uninitialized arg type is rewritten
to MethodClass, the type of the method holder
of <init>. We check whether there really is a new instruction
at Address.

The rule for invokespecial of an <init> method is
the sole motivation for passing back a distinct exception stack
frame. The concern is that when initializing an object within its
constructor, invokespecial can cause a superclass <init> method to
be invoked, and that invocation could fail, leaving this
uninitialized. This situation cannot be created using source code in
the Java programming language, but can be created by programming in bytecode
directly.

In this situation, the original frame holds an
uninitialized object in local variable 0 and has flag
flagThisUninit. Normal termination of invokespecial initializes
the uninitialized object and turns off the flagThisUninit flag. But
if the invocation of an <init> method throws an exception, the
uninitialized object might be left in a partially initialized state,
and needs to be made permanently unusable. This is represented by an
exception frame containing the broken object (the new value of the
local) and the flagThisUninit flag (the old flag). There is no way
to get from an apparently-initialized object bearing the
flagThisUninit flag to a properly initialized object, so the object
is permanently unusable.

If not for this situation, the flags of the
exception stack frame would always be the same as the flags of the
input stack frame.

invokestatic

An invokestatic instruction is type safe iff all of the following
are true:

Its first operand, CP, refers to a constant pool entry
denoting a method named MethodName with
descriptor Descriptor.

MethodName is not <init>.

MethodName is not <clinit>.

One can validly replace types matching the argument types given
in Descriptor on the incoming operand stack
with the return type given in Descriptor,
yielding the outgoing type state.

invokevirtual

An invokevirtual instruction is type safe iff all of the following
are true:

Its first operand, CP, refers to a constant pool entry
denoting a method named MethodName with
descriptor Descriptor that is a member of a
class MethodClassName.

MethodName is not <init>.

MethodName is not <clinit>.

One can validly replace types matching the
class MethodClassName and the argument types
given in Descriptor on the incoming operand
stack with the return type given
in Descriptor, yielding the outgoing type
state.

If the method is protected, the usage conforms to the special
rules governing access to protected members
(§4.10.1.8).

istore, istore_<n>

An istore instruction with operand Index is type
safe and yields an outgoing type
state NextStackFrame, if a store instruction with
operand Index and type int is type safe and
yields an outgoing type
state NextStackFrame.

ldc, ldc_w, ldc2_w

An ldc instruction with operand CP is type safe iff CP refers to
a constant pool entry denoting an entity of type Type, where Type
is either int, float, String, Class, java.lang.invoke.MethodType, or
java.lang.invoke.MethodHandle, and one can validly push Type onto the incoming
operand stack yielding the outgoing type state.

An ldc2_w instruction with operand CP is type safe iff CP refers
to a constant pool entry denoting an entity of
type Tag, where Tag is either
long or double, and one can validly push Tag
onto the incoming operand stack yielding the outgoing type
state.

ldiv

lload, lload_<n>

An lload instruction with operand Index is type
safe and yields an outgoing type
state NextStackFrame, if a load instruction with
operand Index and type long is type safe and
yields an outgoing type
state NextStackFrame.

lookupswitch

A lookupswitch instruction is type safe if its keys are sorted, one
can validly pop int off the incoming operand stack yielding a new
type state BranchStackFrame, and all of the
instruction's targets are valid branch targets
assuming BranchStackFrame as their incoming type
state.

lstore, lstore_<n>

An lstore instruction with operand Index is type
safe and yields an outgoing type
state NextStackFrame, if a store instruction with
operand Index and type long is type safe and
yields an outgoing type
state NextStackFrame.

monitorexit

multianewarray

A multianewarray instruction with operands CP
and Dim is type safe iff CP refers to a constant
pool entry denoting an array type whose dimension is greater or equal
to Dim, Dim is strictly
positive, and one can validly replace Dimint
types on the incoming operand stack with the type denoted by CP
yielding the outgoing type state.

new

A new instruction with operand CP at
offset Offset is type safe iff CP refers to a
constant pool entry denoting a class type, the type
uninitialized(Offset) does not appear in the incoming operand stack,
and one can validly push uninitialized(Offset) onto the incoming
operand stack and replace uninitialized(Offset) with top in the
incoming local variables yielding the outgoing type state.

The substitute predicate is
defined in the rule for invokespecial
(§invokespecial).

newarray

A newarray instruction with operand TypeCode is
type safe iff TypeCode corresponds to the primitive
type ElementType, and one can validly replace the
type int on the incoming operand stack with the type 'array
of ElementType', yielding the outgoing type
state.

A pop2 instruction is a type safe form 2pop2
instruction iff one can validly pop a type of size 2 off the incoming
operand stack yielding the outgoing type state.

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

putfield

A putfield instruction with operand CP is type safe iff CP
refers to a constant pool entry denoting a field whose declared type
is FieldType, declared in a
class FieldClass, and one can validly pop types
matching FieldType
and FieldClass off the incoming operand stack
yielding the outgoing type state.

putstatic

A putstatic instruction with operand CP is type safe iff CP
refers to a constant pool entry denoting a field whose declared type
is FieldType, and one can validly pop a type
matching FieldType off the incoming operand stack
yielding the outgoing type state.

tableswitch

A tableswitch instruction is type safe if its keys are sorted, one
can validly pop int off the incoming operand stack yielding a new
type state BranchStackFrame, and all of the
instruction's targets are valid branch targets
assuming BranchStackFrame as their incoming type
state.

wide

4.10.2. Verification by Type Inference

A class file that does
not contain a StackMapTable attribute (which necessarily has a
version number of 49.0 or below) must be verified using type
inference.

4.10.2.1. The Process of Verification by Type Inference

During linking, the
verifier checks the code array of the Code attribute for each
method of the class file by performing data-flow analysis on each
method. The verifier ensures that at any given point in the program,
no matter what code path is taken to reach that point, all of the
following are true:

The operand stack is always the same size and contains the same
types of values.

No local variable is accessed unless it is known to contain a
value of an appropriate type.

Methods are invoked with the appropriate arguments.

Fields are assigned only using values of appropriate
types.

All opcodes have appropriately typed arguments on the operand
stack and in the local variable array.

For efficiency reasons,
certain tests that could in principle be performed by the verifier are
delayed until the first time the code for the method is actually
invoked. In so doing, the verifier avoids loading class files unless
it has to.

For example, if a method invokes another method that
returns an instance of class A, and that instance is assigned only
to a field of the same type, the verifier does not bother to check if
the class A actually exists. However, if it is assigned to a field
of the type B, the definitions of both A and B must be loaded in
to ensure that A is a subclass of B.

4.10.2.2. The Bytecode Verifier

The code for each method
is verified independently. First, the bytes that make up the code are
broken up into a sequence of instructions, and the index into the
code array of the start of each instruction is placed in an
array. The verifier then goes through the code a second time and
parses the instructions. During this pass a data structure is built to
hold information about each Java Virtual Machine instruction in the method. The
operands, if any, of each instruction are checked to make sure they
are valid. For instance:

Branches must be
within the bounds of the code array for the method.

The targets of all
control-flow instructions are each the start of an
instruction. In the case of a wide instruction, the wide
opcode is considered the start of the instruction, and the
opcode giving the operation modified by that wide instruction
is not considered to start an instruction. Branches into the
middle of an instruction are disallowed.

No instruction can
access or modify a local variable at an index greater than or
equal to the number of local variables that its method indicates
it allocates.

All references to
the constant pool must be to an entry of the appropriate
type. (For example, the instruction getfield must reference a
field.)

The code does not
end in the middle of an instruction.

Execution cannot
fall off the end of the code.

For each exception
handler, the starting and ending point of code protected by the
handler must be at the beginning of an instruction or, in the
case of the ending point, immediately past the end of the
code. The starting point must be before the ending point. The
exception handler code must start at a valid instruction, and it
must not start at an opcode being modified by the wide
instruction.

For each instruction of
the method, the verifier records the contents of the operand stack and
the contents of the local variable array prior to the execution of
that instruction. For the operand stack, it needs to know the stack
height and the type of each value on it. For each local variable, it
needs to know either the type of the contents of that local variable
or that the local variable contains an unusable or unknown value (it
might be uninitialized). The bytecode verifier does not need to
distinguish between the integral types (e.g., byte, short, char)
when determining the value types on the operand stack.

Next, a data-flow
analyzer is initialized. For the first instruction of the method, the
local variables that represent parameters initially contain values of
the types indicated by the method's type descriptor; the operand stack
is empty. All other local variables contain an illegal value. For the
other instructions, which have not been examined yet, no information
is available regarding the operand stack or local variables.

Finally, the data-flow
analyzer is run. For each instruction, a "changed" bit indicates
whether this instruction needs to be looked at. Initially, the
"changed" bit is set only for the first instruction. The data-flow
analyzer executes the following loop:

Select a Java Virtual Machine
instruction whose "changed" bit is set. If no instruction remains
whose "changed" bit is set, the method has successfully been
verified. Otherwise, turn off the "changed" bit of the selected
instruction.

Model the effect of
the instruction on the operand stack and local variable array by
doing the following:

If the
instruction uses values from the operand stack, ensure that
there are a sufficient number of values on the stack and that
the top values on the stack are of an appropriate
type. Otherwise, verification fails.

If the
instruction uses a local variable, ensure that the specified
local variable contains a value of the appropriate
type. Otherwise, verification fails.

If the
instruction pushes values onto the operand stack, ensure that
there is sufficient room on the operand stack for the new
values. Add the indicated types to the top of the modeled
operand stack.

If the
instruction modifies a local variable, record that the local
variable now contains the new type.

Determine the
instructions that can follow the current instruction. Successor
instructions can be one of the following:

The next
instruction, if the current instruction is not an
unconditional control transfer instruction (for instance,
goto, return, or athrow). Verification fails if it is
possible to "fall off" the last instruction of the
method.

The target(s)
of a conditional or unconditional branch or switch.

Any exception
handlers for this instruction.

Merge the state of
the operand stack and local variable array at the end of the
execution of the current instruction into each of the successor
instructions.

In the special
case of control transfer to an exception handler, the operand
stack is set to contain a single object of the exception type
indicated by the exception handler information. There must be
sufficient room on the operand stack for this single value, as if
an instruction had pushed it.

If this is
the first time the successor instruction has been visited,
record that the operand stack and local variable values
calculated in steps 2 and 3 are the state of the operand stack
and local variable array prior to executing the successor
instruction. Set the "changed" bit for the successor
instruction.

If the
successor instruction has been seen before, merge the operand
stack and local variable values calculated in steps 2 and 3
into the values already there. Set the "changed" bit if there
is any modification to the values.

Continue at step
1.

To merge two operand stacks, the
number of values on each stack must be identical. Then, corresponding
values on the two stacks are compared and the value on the merged
stack is computed, as follows:

If one value is a primitive type, then the corresponding value
must be the same primitive type. The merged value is the
primitive type.

If one value is a non-array reference type, then the
corresponding value must be a reference type (array or
non-array). The merged value is a reference to an instance of
the first common supertype of the two reference types. (Such a
reference type always exists because the type Object is a
supertype of all class, interface, and array types.)

For example, Object and String can be
merged; the result is Object. Similarly, Object and
String[] can be merged; the result is again
Object. Even Object and int[] can be merged, or
String and int[]; the result is Object for
both.

If corresponding values are both array reference types, then
their dimensions are examined. If the array types have the same
dimensions, then the merged value is a reference to an instance of
an array type which is first common supertype of both array
types. (If either or both of the array types has a primitive
element type, then Object is used as the element type
instead.) If the array types have different dimensions, then the
merged value is a reference to an instance of an array type whose
dimension is the smaller of the two; the element type is
Cloneable or java.io.Serializable if the smaller array type was
Cloneable or java.io.Serializable, and Object otherwise.

For example, Object[] and
String[] can be merged; the result is
Object[]. Cloneable[] and String[]
can be merged, or java.io.Serializable[] and
String[]; the result is Cloneable[] and
java.io.Serializable[] respectively. Even int[] and
String[] can be merged; the result is
Object[], because Object is used instead of int
when computing the first common supertype.

Since the array types can have different
dimensions, Object[] and String[][]
can be merged, or Object[][] and
String[]; in both cases the result is
Object[]. Cloneable[] and
String[][] can be merged; the result is
Cloneable[]. Finally, Cloneable[][]
and String[] can be merged; the result is
Object[].

If the operand stacks cannot be
merged, verification of the method fails.

To merge two local variable array
states, corresponding pairs of local variables are compared. The value
of the merged local variable is computed using the rules above, except
that the corresponding values are permitted to be different primitive
types. In that case, the verifier records that the merged local
variable contains an unusable value.

If the data-flow analyzer
runs on a method without reporting a verification failure, then the
method has been successfully verified by the class file
verifier.

Certain instructions and
data types complicate the data-flow analyzer. We now examine each of
these in more detail.

4.10.2.3. Values of Types long and double

Values of the long and
double types are treated specially by the verification
process.

Whenever a value of type
long or double is moved into a local variable at index n,
index n+1 is specially marked to indicate that it has been
reserved by the value at index n and must not be used as a local
variable index. Any value previously at index n+1 becomes
unusable.

Whenever a value is moved
to a local variable at index n, the index n-1 is examined to
see if it is the index of a value of type long or double. If so,
the local variable at index n-1 is changed to indicate that it
now contains an unusable value. Since the local variable at index
n has been overwritten, the local variable at index n-1
cannot represent a value of type long or double.

Dealing with values of
types long or double on the operand stack is simpler; the verifier
treats them as single values on the stack. For example, the
verification code for the dadd opcode (add two double values)
checks that the top two items on the stack are both of type
double. When calculating operand stack length, values of type long
and double have length two.

Untyped instructions that
manipulate the operand stack must treat values of type long and
double as atomic (indivisible). For example, the verifier reports a
failure if the top value on the stack is a double and it encounters
an instruction such as pop or dup. The instructions pop2 or
dup2 must be used instead.

This instruction sequence
leaves the newly created and initialized object on top of the operand
stack. (Additional examples of compilation to the instruction set of
the Java Virtual Machine are given in §3 (Compiling for the Java Virtual Machine).)

The instance
initialization method (§2.9) for
class myClass sees the new uninitialized object as
its this argument in local variable 0. Before that method invokes
another instance initialization method of myClass
or its direct superclass on this, the only operation the method can
perform on this is assigning fields declared
within myClass.

When doing dataflow
analysis on instance methods, the verifier initializes local variable
0 to contain an object of the current class, or, for instance
initialization methods, local variable 0 contains a special type
indicating an uninitialized object. After an appropriate instance
initialization method is invoked (from the current class or its direct
superclass) on this object, all occurrences of this special type on
the verifier's model of the operand stack and in the local variable
array are replaced by the current class type. The verifier rejects
code that uses the new object before it has been initialized or that
initializes the object more than once. In addition, it ensures that
every normal return of the method has invoked an instance
initialization method either in the class of this method or in the
direct superclass.

Similarly, a special type
is created and pushed on the verifier's model of the operand stack as
the result of the Java Virtual Machine instruction new. The special type indicates
the instruction by which the class instance was created and the type
of the uninitialized class instance created. When an instance
initialization method declared in the class of the uninitialized class
instance is invoked on that class instance, all occurrences of the
special type are replaced by the intended type of the class
instance. This change in type may propagate to subsequent instructions
as the dataflow analysis proceeds.

The instruction number
needs to be stored as part of the special type, as there may be
multiple not-yet-initialized instances of a class in existence on the
operand stack at one time. For example, the Java Virtual Machine instruction sequence
that implements:

new InputStream(new Foo(), new InputStream("foo"))

may have two
uninitialized instances of InputStream on the
operand stack at once. When an instance initialization method is
invoked on a class instance, only those occurrences of the special
type on the operand stack or in the local variable array that are the
same object as the class instance are replaced.

4.10.2.5. Exceptions and finally

To implement the
try-finally construct, a compiler for the Java programming language that
generates class files with version number 50.0 or below may use the
exception-handling facilities together with two special instructions:
jsr ("jump to subroutine") and ret ("return from subroutine"). The
finally clause is compiled as a subroutine within the Java Virtual Machine code for
its method, much like the code for an exception handler. When a jsr
instruction that invokes the subroutine is executed, it pushes its
return address, the address of the instruction after the jsr that is
being executed, onto the operand stack as a value of type
returnAddress. The code for the subroutine stores the return address
in a local variable. At the end of the subroutine, a ret instruction
fetches the return address from the local variable and transfers
control to the instruction at the return address.

Control can be
transferred to the finally clause (the finally subroutine can be
invoked) in several different ways. If the try clause completes
normally, the finally subroutine is invoked via a jsr instruction
before evaluating the next expression. A break or continue inside
the try clause that transfers control outside the try clause
executes a jsr to the code for the finally clause first. If the
try clause executes a return, the compiled code does the
following:

Saves the return
value (if any) in a local variable.

Executes a jsr to
the code for the finally clause.

Upon return from
the finally clause, returns the value saved in the local
variable.