VM Spec Java Programming Language Concepts

Contents | Prev | Next | Index | The JavaTM TMVirtual Machine Specification

CHAPTER 2

# Java Programming Language Concepts

The Java virtual machine was designed to support the Java programming language. Some concepts and vocabulary from the Java programming language are thus useful when attempting to understand the virtual machine. This chapter gives an overview intended to support the specification of the Java virtual machine, but is not itself a part of that specification.

The content of this chapter has been condensed from the first edition of The JavaTM Language Specification, by James Gosling, Bill Joy, and Guy Steele.1 Readers familiar with the Java programming language, but not with The JavaTM Language Specification, should at least skim this chapter for the terminology it introduces. Any discrepancies between this chapter and The JavaTM Language Specification should be resolved in favor of The JavaTM Language Specification.

This chapter does not attempt to provide an introduction to the Java programming language. For such an introduction, see The JavaTM Programming Language, Second Edition, by Ken Arnold and James Gosling.

## 2.1 Unicode

Programs written in the Java programming language supported by JDK release 1.1.7 and the Java 2 platform, v1.2 use the Unicode character encoding, version 2.1, as specified in The Unicode Standard, Version 2.0, ISBN 0-201-48345-9, and the update information for Version 2.1 of the Unicode Standard available at `http:// www.unicode.org`. Programs written in the Java programming language used version 2.0.14 of the Unicode Standard in JDK releases 1.1 through 1.1.6 and used version 1.1.5 of the Unicode Standard in JDK release 1.0.

Except for comments, identifiers (§2.2), and the contents of character and string literals (§2.3), all input elements in a program written in the Java programming language are formed from only ASCII characters. ASCII (ANSI X3.4) is the American Standard Code for Information Interchange. The first 128 characters of the Unicode character encoding are the ASCII characters.

## 2.2 Identifiers

An identifier is an unlimited-length sequence of Unicode letters and digits, the first of which must be a letter. Letters and digits may be drawn from the entire Unicode character set, which supports most writing scripts in use in the world today. This allows programmers to use identifiers in their programs that are written in their native languages.

The method (§2.10) `Character.isJavaLetter` returns `true` when passed a Unicode character that is considered to be a letter in an identifier. The method `Character.isJavaLetterOrDigit` returns `true` when passed a Unicode character that is considered to be a letter or digit in an identifier.

Two identifiers are the same only if they have the same Unicode character for each letter or digit; identifiers that have the same external appearance may still be different. An identifier must not be the same as a boolean literal (§2.3), the null literal (§2.3), or a keyword in the Java programming language.

## 2.3 Literals

A literal is the source code representation of a value of a primitive type (§2.4.1), the `String` type (§2.4.8), or the null type (§2.4). String literals and, more generally, strings that are the values of constant expressions are "interned" so as to share unique instances, using the method `String.intern`.

The null type has one value, the null reference, denoted by the literal `null`. The `boolean` type has two values, denoted by the literals `true` and `false`.

## 2.4 Types and Values

The Java programming language is strongly typed, which means that every variable and every expression has a type that is known at compile time. Types limit the values that a variable (§2.5) can hold or that an expression can produce, limit the operations supported on those values, and determine the meaning of those operations. Strong typing helps detect errors at compile time.

The types of the Java programming language are divided into two categories: primitive types (§2.4.1) and reference types (§2.4.6). There is also a special null type, the type of the expression `null`, which has no name. The null reference is the only possible value of an expression of null type and can always be converted to any reference type. In practice, the programmer can ignore the null type and just pretend that `null` is a special literal that can be of any reference type.

Corresponding to the primitive types and reference types, there are two categories of data values that can be stored in variables, passed as arguments, returned by methods, and operated upon: primitive values (§2.4.1) and reference values (§2.4.6).

### 2.4.1 Primitive Types and Values

A primitive type is a type that is predefined by the Java programming language and named by a reserved keyword. Primitive values do not share state with other primitive values. A variable whose type is a primitive type always holds a primitive value of that type.2

The primitive types are the `boolean` type and the numeric types. The numeric types are the integral types and the floating-point types.

The integral types are `byte`, `short`, `int`, and `long`, whose values are 8-bit, 16-bit, 32-bit, and 64-bit signed two's-complement integers, respectively, and `char`, whose values are 16-bit unsigned integers representing Unicode characters (§2.1).

The floating-point types are `float` and `double`, which are conceptually associated with the 32-bit single-precision and 64-bit double-precision IEEE 754 values and operations as specified in IEEE Standard for Binary Floating-Point Arithmetic, ANSI/IEEE Standard 754-1985 (IEEE, New York).

The `boolean` type has the truth values `true` and `false`.

### 2.4.2 Operators on Integral Values

The Java programming language provides a number of operators that act on integral values, including numerical comparison, arithmetic operators, increment and decrement, bitwise logical and shift operators, and numeric cast (§2.6.9).

Operands of certain unary and binary operators are subject to numeric promotion (§2.6.10).

The built-in integer operators do not indicate (positive or negative) overflow in any way; they wrap around on overflow. The only integer operators that can throw an exception are the integer divide and integer remainder operators, which can throw an `ArithmeticException` if the right-hand operand is zero.

Any value of any integral type may be cast to or from any numeric type. There are no casts between integral types and the type `boolean`.

### 2.4.3 Floating-Point Types, Value Sets, and Values

The IEEE 754 standard includes not only positive and negative sign-magnitude numbers, but also positive and negative zeros, positive and negative infinities, and a special Not-a-Number value (hereafter abbreviated as "NaN"). The NaN value is used to represent the result of certain invalid operations such as dividing zero by zero.

Every implementation of the Java programming language is required to support two standard sets of floating-point values, called the float value set and the double value set. In addition, an implementation of the Java programming language may support either or both of two extended-exponent floating-point value sets, called the float-extended-exponent value set and the double-extended-exponent value set. These extended-exponent value sets may, under certain circumstances, be used instead of the standard value sets to represent the values of expressions of type float or double.

The finite nonzero values of any floating-point value set can all be expressed in the form s · m· 2(e -N + 1), where s is +1 or -1, m is a positive integer less than 2N, and e is an integer between Emin = - (2K - 1-2) and Emax = 2K - 1-1, inclusive, and where N and K are parameters that depend on the value set. Some values can be represented in this form in more than one way; for example, supposing that a value v in a value set might be represented in this form using certain values for s, m, and e, then if it happened that m was even and e was less than 2K -1, one could halve m and increase e by 1 to produce a second representation for the same value v. A representation in this form is called normalized if m 2N -1; otherwise the representation is said to be denormalized. If a value in a value set cannot be represented in such a way that m 2N -1, then the value is said to be a denormalized value, because it has no normalized representation.

The constraints on the parameters N and K (and on the derived parameters Emin and Emax) for the two required and two optional floating-point value sets are summarized in Table 2.1.

Parameter | float | float-extended-exponent | double | double-extended-exponent
--- | --- | --- | --- | ---
N | 24 | 24 | 53 | 53
K | 8 | 11 | 11 | 15
Emax | +127 | +1023 | +1023 | +16383
Emin | -126 | -1022 | -1022 | -16382

Where one or both extended-exponent value sets are supported by an implementation, then for each supported extended-exponent value set there is a specific implementation-dependent constant K, whose value is constrained by Table 2.1; this value K in turn dictates the values for Emin and Emax.

Each of the four value sets includes not only the finite nonzero values that are ascribed to it above, but also the five values positive zero, negative zero, positive infinity, negative infinity, and NaN.

Note that the constraints in Table 2.1 are designed so that every element of the float value set is necessarily also an element of the float-extended-exponent value set, the double value set, and the double-extended-exponent value set. Likewise, each element of the double value set is necessarily also an element of the double-extended-exponent value set. Each extended-exponent value set has a larger range of exponent values than the corresponding standard value set, but does not have more precision.

The elements of the float value set are exactly the values that can be represented using the single floating-point format defined in the IEEE 754 standard, except that there is only one NaN value (IEEE 754 specifies 224 - 2 distinct NaN values). The elements of the double value set are exactly the values that can be represented using the double floating-point format defined in the IEEE 754 standard, except that there is only one NaN value (IEEE 754 specifies 253 - 2 distinct NaN values). Note, however, that the elements of the float-extended-exponent and double-extended-exponent value sets defined here do not correspond to the values that can be represented using IEEE 754 single extended and double extended formats, respectively.

The float, float-extended-exponent, double, and double-extended-exponent value sets are not types. It is always correct for an implementation of the Java programming language to use an element of the float value set to represent a value of type float; however, it may be permissible in certain regions of code for an implementation to use an element of the float-extended-exponent value set instead. Similarly, it is always correct for an implementation to use an element of the double value set to represent a value of type double; however, it may be permissible in certain regions of code for an implementation to use an element of the double-extended-exponent value set instead.

Except for NaN, floating-point values are ordered; arranged from smallest to largest, they are negative infinity, negative finite nonzero values, positive and negative zero, positive finite nonzero values, and positive infinity.

On comparison, positive zero and negative zero are equal; thus the result of the expression 0.0 == -0.0 is true and the result of 0.0 > -0.0 is false. But other operations can distinguish positive and negative zero; for example, 1.0/0.0 has the value positive infinity, while the value of 1.0/-0.0 is negative infinity.

NaN is unordered, so the numerical comparison operators <, <=, >, and >= return false if either or both operands are NaN. The equality operator == returns false if either operand is NaN, and the inequality operator != returns true if either operand is NaN. In particular, x != x is true if and only if x is NaN, and (x<y) == !(x>=y) will be false if x or y is NaN.

Any value of a floating-point type may be cast to or from any numeric type. There are no casts between floating-point types and the type boolean.

### 2.4.4 Operators on Floating-Point Values

The Java programming language provides a number of operators that act on floating-point values, including numerical comparison, arithmetic operators, increment and decrement, and numeric cast (§2.6.9).

If at least one of the operands to a binary operator is of floating-point type, then the operation is a floating-point operation, even if the other operand is integral. Operands of certain unary and binary operators are subject to numeric promotion (§2.6.10).

The values returned by operators on floating-point numbers are those specified by IEEE 754. In particular, the Java programming language requires support of IEEE 754 denormalized floating-point numbers and gradual underflow, which make it easier to prove desirable properties of particular numerical algorithms.

The Java programming language requires that floating-point arithmetic behave as if every floating-point operator rounded its floating-point result to the result precision. Inexact results must be rounded to the representable value nearest to the infinitely precise result; if the two nearest representable values are equally near, the one having zero as its least significant bit is chosen. This is the IEEE 754 standard's default rounding mode known as round to nearest mode.

When converting a floating-point value to an integer, round towards zero mode is used (§2.6.3). Round towards zero mode acts as though the number were truncated, discarding the significand bits. Round towards zero mode chooses as its result the format's value closest to and no greater in magnitude than the infinitely precise result.

The floating-point operators of the Java programming language produce no exceptions (§2.16). An operation that overflows produces a signed infinity; an operation that underflows produces a denormalized value or a signed zero; and an operation that has no mathematically definite result produces NaN. All numeric operations (except for numeric comparison) with NaN as an operand produce NaN as a result.

Any value of any floating-point type may be cast (§2.6.9) to or from any numeric type. There are no casts between floating-point types and the type `boolean`.

### 2.4.5 Operators on `boolean` Values

The boolean operators include relational operators and logical operators. Only `boolean` expressions can be used in control flow statements and as the first operand of the conditional operator `?:`. An integral value `x` can be converted to a value of type `boolean`, following the C language convention that any nonzero value is `true`, by the expression `x!=0`. An object reference `obj` can be converted to a value of type `boolean`, following the C language convention that any reference other than `null` is `true`, by the expression `obj!=null`.

There are no casts between the type `boolean` and any other type.

### 2.4.6 Reference Types, Objects, and Reference Values

There are three kinds of reference types: the class types (§2.8), the interface types (§2.13), and the array types (§2.15). An object is a dynamically created class instance or an array. The reference values (often just references) are pointers to these objects and a special null reference, which refers to no object.

A class instance is explicitly created by a class instance creation expression, or by invoking the `newInstance` method of class `Class`. An array is explicitly created by an array creation expression. An object is created in the heap and is garbage-collected after there are no more references to it. Objects cannot be reclaimed or freed by explicit language directives.

There may be many references to the same object. Most objects have state, stored in the fields of objects that are instances of classes or in the variables that are the components of an array object. If two variables contain references to the same object, the state of the object can be modified using one variable's reference to the object, and then the altered state can be observed through the other variable's reference.

Each object has an associated lock (§2.19, §8.13) that is used by `synchronized` methods and by the `synchronized` statement to provide control over concurrent access to state by multiple threads (§2.19, §8.12).

Reference types form a hierarchy. Each class type is a subclass of another class type, except for the class `Object` (§2.4.7), which is the superclass (§2.8.3) of all other class and array types. All objects, including arrays, support the methods of class `Object`. String literals (§2.3) are references to instances of class `String` (§2.4.8).

### 2.4.7 The Class `Object`

The standard class `Object` is the superclass (§2.8.3) of all other classes. A variable of type `Object` can hold a reference to any object, whether it is an instance of a class or an array. All class and array types inherit the methods of class `Object`.

### 2.4.8 The Class `String`

Instances of class `String` represent sequences of Unicode characters (§2.1). A `String` object has a constant, unchanging value. String literals (§2.3) are references to instances of class `String`.

### 2.4.9 Operators on Objects

The operators on objects include field access, method invocation, cast, string concatenation, comparison for equality, `instanceof`, and the conditional operator `?:`.

## 2.5 Variables

A variable is a storage location. It has an associated type, sometimes called its compile-time type, that is either a primitive type (§2.4.1) or a reference type (§2.4.6). A variable always contains a value that is assignment compatible (§2.6.7) with its type. A variable of a primitive type always holds a value of that exact primitive type. A variable of reference type can hold either a null reference or a reference to any object whose class is assignment compatible (§2.6.7) with the type of the variable.

Compatibility of the value of a variable with its type is guaranteed by the design of the language because default values (§2.5.1) are compatible and all assignments to a variable are checked, at compile time, for assignment compatibility. There are seven kinds of variables:

1. A class variable is a field of a class type declared using the keyword `static` (§2.9.1) within a class declaration, or with or without the keyword `static` in an interface declaration. Class variables are created when the class or interface is loaded (§2.17.2) and are initialized on creation to default values (§2.5.1). The class variable effectively ceases to exist when its class or interface is unloaded (§2.17.8).

2. An instance variable is a field declared within a class declaration without using the keyword `static` (§2.9.1). If a class T has a field a that is an instance variable, then a new instance variable a is created and initialized to a default value (§2.5.1) as part of each newly created object of class T or of any class that is a subclass of T. The instance variable effectively ceases to exist when the object of which it is a field is no longer referenced, after any necessary finalization of the object (§2.17.7) has been completed.

3. Array components are unnamed variables that are created and initialized to default values (§2.5.1) whenever a new object that is an array is created (§2.17.6). The array components effectively cease to exist when the array is no longer referenced.

4. Method parameters name argument values passed to a method. For every parameter declared in a method declaration, a new parameter variable is created each time that method is invoked. The new variable is initialized with the corresponding argument value from the method invocation. The method parameter effectively ceases to exist when the execution of the body of the method is complete.

5. Constructor parameters name argument values passed to a constructor. For every parameter declared in a constructor declaration, a new parameter variable is created each time a class instance creation expression or explicit constructor invocation is evaluated. The new variable is initialized with the corresponding argument value from the creation expression or constructor invocation. The constructor parameter effectively ceases to exist when the execution of the body of the constructor is complete.

6. An exception-handler parameter variable is created each time an exception is caught by a `catch` clause of a `try` statement (§2.16.2). The new variable is initialized with the actual object associated with the exception (§2.16.3). The exception-handler parameter effectively ceases to exist when execution of the block associated with the `catch` clause (§2.16.2) is complete.

7. Local variables are declared by local variable declaration statements. Whenever the flow of control enters a block or a `for` statement, a new variable is created for each local variable declared in a local variable declaration statement immediately contained within that block or `for` statement. The local variable is not initialized, however, until the local variable declaration statement that declares it is executed. The local variable effectively ceases to exist when the execution of the block or `for` statement is complete.

### 2.5.1 Initial Values of Variables

Every variable in a program must have a value before it is used:

- Each class variable, instance variable, and array component is initialized with a default value when it is created:

- For type `byte`, the default value is zero, that is, the value of `(byte)0`.

- For type `short`, the default value is zero, that is, the value of `(short)0`.

- For type `int`, the default value is zero, that is, `0`.

- For type `long`, the default value is zero, that is, `0L`.

- For type `float`, the default value is positive zero, that is, `0.0f`.

- For type `double`, the default value is positive zero, that is, `0.0`.

- For type `char`, the default value is the null character, that is, `'\u0000'`.

- For type `boolean`, the default value is `false`.

- For all reference types (§2.4.6), the default value is `null` (§2.3).

- Each method parameter (§2.5) is initialized to the corresponding argument value provided by the invoker of the method.

- Each constructor parameter (§2.5) is initialized to the corresponding argument value provided by an object creation expression or explicit constructor invocation.

- An exception-handler parameter (§2.16.2) is initialized to the thrown object representing the exception (§2.16.3).

- A local variable must be explicitly given a value, by either initialization or assignment, before it is used.

### 2.5.2 Variables Have Types, Objects Have Classes

Every object belongs to some particular class. This is the class that was mentioned in the class instance creation expression that produced the object, or the class whose class object was used to invoke the `newInstance` method to produce the object. This class is called the class of the object. An object is said to be an instance of its class and of all superclasses of its class. Sometimes the class of an object is called its "runtime type," but "class" is the more accurate term.

(Sometimes a variable or expression is said to have a "runtime type," but that is an abuse of terminology; it refers to the class of the object referred to by the value of the variable or expression at run time, assuming that the value is not `null`. Properly speaking, type is a compile-time notion. A variable or expression has a type; an object or array has no type, but belongs to a class.)

The type of a variable is always declared, and the type of an expression can be deduced at compile time. The type limits the possible values that the variable can hold or the expression can produce at run time. If a runtime value is a reference that is not `null`, it refers to an object or array that has a class (not a type), and that class will necessarily be compatible with the compile-time type.

Even though a variable or expression may have a compile-time type that is an interface type, there are no instances of interfaces (§2.13). A variable or expression whose type is an interface type can reference any object whose class implements that interface.

Every array also has a class. The classes for arrays have strange names that are not valid identifiers; for example, the class for an array of `int` components has the name `"[I"`.

## 2.6 Conversions and Promotions

A conversion from type S to type T allows an expression of type S to be treated at compile time as if it were of type T instead. In some cases this will require a corresponding action at run time to check the validity of the conversion or to translate the runtime value of the expression into a form appropriate for the new type T.

Numeric promotions are conversions that change an operand of a numeric operation to a wider type, or both operands of a numeric operation to a common type, so that an operation can be performed.

In the Java programming language, there are six broad kinds of conversions:

- Identity conversions

- Widening primitive conversions

- Narrowing primitive conversions

- Widening reference conversions

- Narrowing reference conversions

- String conversions

There are five conversion contexts in which conversion expressions can occur. Each context allows conversions in some of the above-named categories but not others. The conversion contexts are:

- Assignment conversion (§2.6.7), which converts the type of an expression to the type of a specified variable. The conversions permitted for assignment are limited in such a way that assignment conversion never causes an exception.

- Method invocation conversion (§2.6.8), which is applied to each argument in a method or constructor invocation, and, except in one case, performs the same conversions that assignment conversion does. Method invocation conversion never causes an exception.

- Casting conversion (§2.6.9), which converts the type of an expression to a type explicitly specified by a cast operator. It is more inclusive than assignment or method invocation conversion, allowing any specific conversion other than a string conversion, but certain casts to a reference type may cause an exception at run time.

- String conversion, which allows any type to be converted to type `String` (§2.4.8).

- Numeric promotion, which brings the operands of a numeric operator to a common type so that an operation can be performed.

String conversion only applies to operands of the binary `+` and `+=` operators when one of the arguments is a `String`; it will not be covered further.

### 2.6.1 Identity Conversions

A conversion from a type to that same type is permitted for any type.

### 2.6.2 Widening Primitive Conversions

The following conversions on primitive types are called the widening primitive conversions :

- `byte` to `short`, `int`, `long`, `float`, or `double`

- `short` to `int`, `long`, `float`, or `double`

- `char` to `int`, `long`, `float`, or `double`

- `int` to `long`, `float`, or `double`

- `long` to `float` or `double`

- `float` to `double`

Widening conversions do not lose information about the sign or order of magnitude of a numeric value. Conversions widening from an integral type to another integral type do not lose any information at all; the numeric value is preserved exactly. Conversions widening from `float` to `double` in `strictfp` expressions (§2.18) also preserve the numeric value exactly; however, such conversions that are not `strictfp` may lose information about the overall magnitude of the converted value.

Conversion of an `int` or a `long` value to `float`, or of a `long` value to `double`, may lose precision, that is, the result may lose some of the least significant bits of the value; the resulting floating-point value is a correctly rounded version of the integer value, using IEEE 754 round to nearest mode (§2.4.4).

According to this rule, a widening conversion of a signed integer value to an integral type simply sign-extends the two's-complement representation of the integer value to fill the wider format. A widening conversion of a value of type `char` to an integral type zero-extends the representation of the character value to fill the wider format.

Despite the fact that loss of precision may occur, widening conversions among primitive types never result in a runtime exception (§2.16).

### 2.6.3 Narrowing Primitive Conversions

The following conversions on primitive types are called narrowing primitive conversions :

- `byte` to `char`

- `short` to `byte` or `char`

- `char` to `byte` or `short`

- `int` to `byte`, `short`, or `char`

- `long` to `byte`, `short`, `char`, or `int`

- `float` to `byte`, `short`, `char`, `int`, or `long`

- `double` to `byte`, `short`, `char`, `int`, `long`, or `float`

Narrowing conversions may lose information about the sign or order of magnitude, or both, of a numeric value (for example, narrowing an `int` value `32763` to type `byte` produces the value `-5`). Narrowing conversions may also lose precision.

A narrowing conversion of a signed integer to an integral type simply discards all but the n lowest-order bits, where n is the number of bits used to represent the type. This may cause the resulting value to have a different sign from the input value.

A narrowing conversion of a character to an integral type likewise simply discards all but the n lowest bits, where n is the number of bits used to represent the type. This may cause the resulting value to be a negative number, even though characters represent 16-bit unsigned integer values.

In a narrowing conversion of a floating-point number to an integral type, if the floating-point number is NaN, the result of the conversion is `0` of the appropriate type. If the floating-point number is too large to be represented by the integral type or is positive infinity, the result is the largest representable value of the integral type. If the floating-point number is too small to be represented or is negative infinity, the result is the smallest representable value of the integral type. Otherwise, the result is the floating-point number rounded towards zero to an integer value using IEEE 754 round towards zero mode (§2.4.4)

A narrowing conversion from `double` to `float` behaves in accordance with IEEE 754. The result is correctly rounded using IEEE 754 round to nearest mode (§2.4.4). A value too small to be represented as a `float` is converted to a positive or negative zero; a value too large to be represented as a `float` is converted to a positive or negative infinity. A `double` ``NaN is always converted to a `float` ``NaN.

Despite the fact that overflow, underflow, or loss of precision may occur, narrowing conversions among primitive types never result in a runtime exception.

### 2.6.4 Widening Reference Conversions

Widening reference conversions never require a special action at run time and therefore never throw an exception at run time. Because they do not affect the Java virtual machine, they will not be considered further.

### 2.6.5 Narrowing Reference Conversions

The following permitted conversions are called the narrowing reference conversions:

- From any class type S to any class type T, provided that S is a superclass of T. (An important special case is that there is a narrowing conversion from the class type `Object` to any other class type.)

- From any class type S to any interface type K, provided that S is not `final` and does not implement K. (An important special case is that there is a narrowing conversion from the class type `Object` to any interface type.)

- From type `Object` to any array type.

- From type `Object` to any interface type.

- From any interface type J to any class type T that is not `final`.

- From any interface type J to any class type T that is `final`, provided that T implements J.

- From any interface type J to any interface type K, provided that J is not a subinterface of K and there is no method name m such that J and K both declare a method named m with the same signature but different return types.

- From any array type SC`[]` to any array type TC`[]`, provided that SC and TC are reference types and there is a permitted narrowing conversion from SC to TC.

Such conversions require a test at run time to find out whether the actual reference value is a legitimate value of the new type. If it is not, the Java virtual machine throws a `ClassCastException`.

### 2.6.6 Value Set Conversion

Value set conversion is the process of mapping a floating-point value from one value set (§2.4.3) to another without changing its type.

For each operation in an expression that is not FP-strict (§2.18), value set conversion allows an implementation of the Java programming language to choose between two options:

- If the value is an element of the float-extended-exponent value set, then the implementation may map the value to the nearest element of the float value set. This conversion may result in overflow (in which case the value is replaced by an infinity of the same sign) or underflow (in which case the value may lose precision because it is replaced by a denormalized number or zero of the same sign).

- If the value is an element of the double-extended-exponent value set, then the implementation may map the value to the nearest element of the double value set. This conversion may result in overflow (in which case the value is replaced by an infinity of the same sign) or underflow (in which case the value may lose precision because it is replaced by a denormalized number or zero of the same sign).

Within an FP-strict expression, value set conversion does not provide any choices; every implementation must behave in the same way:

- If the value is of type float and is not an element of the float value set, then the implementation must map the value to the nearest element of the float value set. This conversion may result in overflow or underflow.

- If the value is of type double and is not an element of the double value set, then the implementation must map the value to the nearest element of the double value set. This conversion may result in overflow or underflow.

Within an FP-strict expression, mapping values from the float-extended-exponent value set or double-extended-exponent value set is necessary only when a method is called whose declaration is not FP-strict and the implementation has chosen to represent the result of the method call as an element of an extended-exponent value set.

Whether in FP-strict code or code that is not FP-strict, value set conversion always leaves unchanged any value whose type is neither float nor double.

### 2.6.7 Assignment Conversion

Assignment conversion occurs when the value of an expression is assigned to a variable: the type of the expression must be converted to the type of the variable. Assignment contexts allow the use of an identity conversion (§2.6.1), a widening primitive conversion (§2.6.2), or a widening reference conversion (§2.6.4). In addition, a narrowing primitive conversion (§2.6.3) may be used if all of the following conditions are satisfied:

- The expression is a constant expression of type `int`.

- The type of the variable is `byte`, `short`, or `char`.

- The value of the expression is representable in the type of the variable.

If the type of the expression can be converted to the type of a variable by assignment conversion, we say the expression (or its value) is assignable to the variable or, equivalently, that the type of the expression is assignment compatible with the type of the variable.

If the type of the variable is `float` or `double`, then value set conversion (§2.6.6) is applied after the type conversion:

- If the value is of type `float` and is an element of the float-extended-exponent value set, then the implementation must map the value to the nearest element of the float value set. This conversion may result in overflow or underflow.

- If the value is of type `double` and is an element of the double-extended-exponent value set, then the implementation must map the value to the nearest element of the double value set. This conversion may result in overflow or underflow.

An assignment conversion never causes an exception. A value of primitive type must not be assigned to a variable of reference type. A value of reference type must not be assigned to a variable of primitive type. A value of type `boolean` can be assigned only to a variable of type `boolean`. A value of the null type may be assigned to a variable of any reference type.

Assignment of a value of compile-time reference type S (source) to a variable of compile-time reference type T (target) is permitted:

- If S is a class type:

  - If T is a class type, then S must be the same class as T, or S must be a subclass of T.

  - If T is an interface type, then S must implement interface T.

- If S is an interface type:

  - If T is a class type, then T must be `Object`.

  - If T is an interface type, then T must be the same interface as S, or T must be a superinterface of S.

- If S is an array type SC`[]`, that is, an array of components of type SC:

  - If T is a class type, then T must be `Object`.

  - If T is an interface type, then T must be either `Cloneable` or `java.io.Serializable`.

  - If T is an array type TC`[]`, that is, an array of components of type TC, then either

    - TC and SC must be the same primitive type, or

    - TC and SC are both reference types and type SC is assignable to TC.

### 2.6.8 Method Invocation Conversion

Method invocation conversion is applied to each argument value in a method or constructor invocation: the type of the argument expression must be converted to the type of the corresponding parameter. Method invocation contexts allow the use of an identity conversion (§2.6.1), a widening primitive conversion (§2.6.2), or a widening reference conversion (§2.6.4). Method invocation conversions specifically do not include the implicit narrowing of integer constants that is part of assignment conversion (§2.6.7).

If the type of an argument expression is either float or double, then value set conversion (§2.6.6) is applied after the type conversion:

- If an argument value of type `float` is an element of the float-extended-exponent value set, then the implementation must map the value to the nearest element of the float value set. This conversion may result in overflow or underflow.

- If an argument value of type `double` is an element of the double-extended-exponent value set, then the implementation must map the value to the nearest element of the double value set. This conversion may result in overflow or underflow.

### 2.6.9 Casting Conversion

Casting conversions are more powerful than assignment or method invocation conversions applied to the operand of a cast operator: the type of the operand expression must be converted to the type explicitly named by the cast operator. Casting contexts allow the use of an identity conversion (§2.6.1), a widening primitive conversion (§2.6.2), a narrowing primitive conversion (§2.6.3), a widening reference conversion (§2.6.4), or a narrowing reference conversion (§2.6.5). Thus, casting conversions are more inclusive than assignment or method invocation conversions: a cast can do any permitted conversion other than a string conversion.

Value set conversion (§2.6.6) is applied after the type conversion.

Casting can convert a value of any numeric type to any other numeric type. A value of type `boolean` cannot be cast to another type. A value of reference type cannot be cast to a value of primitive type.

Some casts can be proven incorrect at compile time and result in a compile-time error. Otherwise, either the cast can be proven correct at compile time, or a runtime validity check is required. (See The JavaTM Language Specification for details.) If the value at run time is a null reference, then the cast is allowed. If the check at run time fails, a `ClassCastException` is thrown.

### 2.6.10 Numeric Promotion

Numeric promotion is applied to the operands of an arithmetic operator. Numeric promotion contexts allow the use of an identity conversion (§2.6.1) or a widening primitive conversion (§2.6.2).

Numeric promotions are used to convert the operands of a numeric operator to a common type where an operation can be performed. The two kinds of numeric promotion are unary numeric promotion and binary numeric promotion. The analogous conversions in C are called "the usual unary conversions" and "the usual binary conversions." Numeric promotion is not a general feature of the Java programming language, but rather a property of specific built-in operators.

An operator that applies unary numeric promotion to a single operand of numeric type converts an operand of type `byte`, `short`, or `char` to `int` by a widening primitive conversion, and otherwise leaves the operand alone. Value set conversion (§2.6.6) is then applied. The operands of the shift operators are promoted independently using unary numeric promotions.

When an operator applies binary numeric promotion to a pair of numeric operands, the following rules apply, in order, using widening primitive conversion to convert operands as necessary:

- If either operand is of type `double`, the other is converted to `double`.

- Otherwise, if either operand is of type `float`, the other is converted to `float`.

- Otherwise, if either operand is of type `long`, the other is converted to `long`.

- Otherwise, both operands are converted to type `int`.

After type conversion, if any, value set conversion is applied to each operand.

## 2.7 Names and Packages

Names are used to refer to entities declared in a program. A declared entity is a package, type, member (field or method) of a type, parameter, or local variable. Programs are organized sets of packages.

### 2.7.1 Simple Names and Qualified Names

A simple name is a single identifier (§2.2). Qualified names (§2.7.4) provide access to members of packages and reference types. A qualified name consists of a name, a "." token, and an identifier.

Not all identifiers are part of a name. Identifiers are also used in declarations, where the identifier determines the name by which an entity will be known, in field access expressions and method invocation expressions, and in statement labels and `break` and `continue` statements that refer to statement labels.

### 2.7.2 Packages

A package consists of a number of compilation units and has a hierarchical name. Packages are independently developed, and each package has its own set of names, which helps to prevent name conflicts. Each Java virtual machine implementation determines how packages, compilation units, and subpackages are created and stored; which top-level package names are in scope in a particular compilation; and which packages are accessible. Packages may be stored in a local file system, in a distributed file system, or in some form of database.

A package name component or class name might contain a character that cannot legally appear in a host file system's ordinary directory or file name: for instance, a Unicode character on a system that allows only ASCII characters in file names.

A Java virtual machine implementation must support at least one unnamed package; it may support more than one but is not required to do so. Which compilation units are in each unnamed package is determined by the host system. Unnamed packages are provided principally for convenience when developing small or temporary applications or when just beginning development.

An `import` declaration allows a type declared in another package to be known by a simple name rather than by the fully qualified name (§2.7.5) of the type. An import declaration affects only the type declarations of a single compilation unit. A compilation unit automatically imports each of the `public` type names declared in the predefined package `java.lang`.

### 2.7.3 Members

Packages and reference types have members. The members of a package (§2.7.2) are subpackages and all the class (§2.8) and interface (§2.13) types declared in all the compilation units of the package. The members of a reference type are fields (§2.9), methods (§2.10), and nested classes and interfaces.

#### 2.7.3.1 The Members of a Package

In general, the subpackages of a package are determined by the host system. However, the standard package `java` always has the subpackages `lang`, `util`, `io`, and `net`. No two distinct members of the same package may have the same simple name (§2.7.1), but members of different packages may have the same simple name.

#### 2.7.3.2 The Members of a Class Type

The members of a class type (§2.8) are fields (§2.9), methods (§2.10), and nested classes and interfaces. These include members inherited from its direct superclass (§2.8.3), if it has one, members inherited from any direct superinterfaces (§2.13.2), and any members declared in the body of the class. There is no restriction against a field and a method of a class type having the same simple name.

A class type may have two or more methods with the same simple name if they have different numbers of parameters or different parameter types in at least one parameter position. Such a method member name is said to be overloaded. A class type may contain a declaration for a method with the same name and the same signature as a method that would otherwise be inherited from a superclass or superinterface. In this case, the method of the superclass or superinterface is not inherited. If the method not inherited is `abstract`, the new declaration is said to implement the method; if it is not `abstract`, the new declaration is said to override it.

#### 2.7.3.3 The Members of an Interface Type

The members of an interface type (§2.13) are fields, methods, and nested classes and interfaces. The members of an interface are the members inherited from any direct superinterfaces (§2.13.2) and members declared in the body of the interface.

#### 2.7.3.4 The Members of an Array Type

The members of an array type (§2.15) are the members inherited from its superclass, the class `Object` (§2.4.7), and the field `length`, which is a constant (`final`) field of every array.

### 2.7.4 Qualified Names and Access Control

Qualified names (§2.7.1) are a means of access to members of packages and reference types; related means of access include field access expressions and method invocation expressions. All three are syntactically similar in that a "." token appears, preceded by some indication of a package, type, or expression having a type and followed by an identifier that names a member of the package or type. These are collectively known as constructs for qualified access.

The Java programming language provides mechanisms for limiting qualified access, to prevent users of a package or class from depending on unnecessary details of the implementation of that package or class. Access control also applies to constructors.

Whether a package is accessible is determined by the host system.

A class or interface may be declared `public`, in which case it may be accessed, using a qualified name, by any class or interface that can access the package in which it is declared. A class or interface that is not declared `public` may be accessed from, and only from, anywhere in the package in which it is declared.

Every field or method of an interface must be `public`. Every member of a `public` interface is implicitly `public`, whether or not the keyword `public` appears in its declaration. It follows that a member of an interface is accessible if and only if the interface itself is accessible.

A field, method, or constructor of a class may be declared using at most one of the `public`, `private`, or `protected` keywords. A `public` member may be accessed by any class or interface. A `private` member may be accessed only from within the class that contains its declaration. A member that is not declared `public`, `protected`, or `private` is said to have default access and may be accessed from, and only from, anywhere in the package in which it is declared.

A `protected` member of an object may be accessed only by code responsible for the implementation of that object. To be precise, a `protected` member may be accessed from anywhere in the package in which it is declared and, in addition, it may be accessed from within any declaration of a subclass of the class type that contains its declaration, provided that certain restrictions are obeyed.

### 2.7.5 Fully Qualified Names

Every package, class, interface, array type, and primitive type has a fully qualified name. It follows that every type except the null type has a fully qualified name.

- The fully qualified name of a primitive type is the keyword for that primitive type, namely, `boolean`, `char`, `byte`, `short`, `int`, `long`, `float`, or `double`.

- The fully qualified name of a named package that is not a subpackage of a named package is its simple name.

- The fully qualified name of a named package that is a subpackage of another named package consists of the fully qualified name of the containing package followed by "`.`" followed by the simple (member) name of the subpackage.

- The fully qualified name of a class or interface that is declared in an unnamed package is the simple name of the class or interface.

- The fully qualified name of a class or interface that is declared in a named package consists of the fully qualified name of the package followed by "`.`" followed by the simple name of the class or interface.

- The fully qualified name of an array type consists of the fully qualified name of the component type of the array type followed by "`[]`".

## 2.8 Classes

A class declaration specifies a new reference type and provides its implementation. Each class is implemented as an extension or subclass of a single existing class. A class may also implement one or more interfaces.

The body of a class declares members (fields and methods), static initializers, and constructors.

### 2.8.1 Class Names

If a class is declared in a named package with the fully qualified name P, then the class has the fully qualified name P`.`Identifier. If the class is in an unnamed package, then the class has the fully qualified name Identifier.

Two classes are the same class (and therefore the same type) if they are loaded by the same class loader (§2.17.2) and they have the same fully qualified name (§2.7.5).

### 2.8.2 Class Modifiers

A class declaration may include class modifiers. A class may be declared `public`, as discussed in §2.7.4.

An `abstract` class is a class that is incomplete, or considered incomplete. Only `abstract` classes may have `abstract` methods (§2.10.3), that is, methods that are declared but not yet implemented.

A class can be declared `final` if its definition is complete and no subclasses are desired or required. Because a `final` class never has any subclasses, the methods of a `final` class cannot be overridden in a subclass. A class cannot be both `final` and `abstract`, because the implementation of such a class could never be completed.

A class can be declared `strictfp``` to indicate that all expressions in the methods of the class are FP-strict (§2.18), whether or not the methods themselves are declared FP-strict.

A class is declared `public` to make its type available to packages other than the one in which it is declared. A `public` class is accessible from other packages, using either its fully qualified name or a shorter name created by an `import` declaration (§2.7.2), whenever the host permits access to its package. If a class lacks the `public` modifier, access to the class declaration is limited to the package in which it is declared.

### 2.8.3 Superclasses and Subclasses

The optional `extends` clause in a class declaration specifies the direct superclass of the current class, the class from whose implementation the implementation of the current class is derived. A class is said to be a direct subclass of the class it `extends`. Only the class `Object` (§2.4.7) has no direct superclass. If the `extends` clause is omitted from a class declaration, then the superclass of the new class is `Object`.

The subclass relationship is the transitive closure of the direct subclass relationship. A class A is a subclass of a class C if A is a direct subclass of C, or if there is a direct subclass B of C and class A is a subclass of B. Class A is said to be a superclass of class C whenever C is a subclass of A.

### 2.8.4 The Class Members

The members of a class type include all of the following:

- Members inherited from its direct superclass (§2.8.3), except in class `Object`, which has no direct superclass.

- Members inherited from any direct superinterfaces (§2.13.2).

- Members declared in the body of the class.

Members of a superclass that are declared `private` are not inherited by subclasses of that class. Members of a class that are not declared `private`, `protected`, or `public` are not inherited by subclasses declared in a package other than the one in which the class is declared. Constructors (§2.12) and static initializers (§2.11) are not members and therefore are not inherited.

## 2.9 Fields

The variables of a class type are its fields. Class (`static`) variables exist once per class. Instance variables exist once per instance of the class. Fields may include initializers and may be modified using various modifier keywords.

If the class declares a field with a certain name, then the declaration of that field is said to hide any and all accessible declarations of fields with the same name in the superclasses and superinterfaces of the class. A class inherits from its direct superclass and direct superinterfaces all the fields of the superclass and superinterfaces that are accessible to code in the class and are not hidden by a declaration in the class. A hidden field can be accessed by using a qualified name (if it is `static`) or by using a field access expression that contains a cast to a superclass type or the keyword `super`.

A value stored in a field of type float is always an element of the float value set (§2.4.3); similarly, a value stored in a field of type double is always an element of the double value set. It is not permitted for a field of type float to contain an element of the float-extended-exponent value set that is not also an element of the float value set, nor for a field of type double to contain an element of the double-extended-exponent value set that is not also an element of the double value set.

### 2.9.1 Field Modifiers

Fields may be declared `public`, `protected`, or `private`, as discussed in §2.7.4.

If a field is declared `static`, there exists exactly one incarnation of the field, no matter how many instances (possibly zero) of the class may eventually be created. A `static` field, sometimes called a class variable, is incarnated when the class is initialized (§2.17.4).

A field that is not declared `static` is called an instance variable. Whenever a new instance of a class is created, a new variable associated with that instance is created for every instance variable declared in that class or in any of its superclasses.

A field can be declared `final`, in which case its declarator must include a variable initializer (§2.9.2). Both class and instance variables (`static` and non-`static` fields) may be declared `final`. Once a `final` field has been initialized, it always contains the same value. If a `final` field holds a reference to an object, then the state of the object may be changed by operations on the object, but the field will always refer to the same object.

Variables may be marked `transient` to indicate that they are not part of the persistent state of an object. The `transient` attribute can be used by an implementation to support special system services. The JavaTM Language Specification does not yet specify details of such services.

The Java programming language allows threads that access shared variables to keep private working copies of the variables; this allows a more efficient implementation of multiple threads (§2.19). These working copies need to be reconciled with the master copies in the shared main memory only at prescribed synchronization points, namely, when objects are locked or unlocked (§2.19). As a rule, to make sure that shared variables are consistently and reliably updated, a thread should ensure that it has exclusive access to such variables by obtaining a lock that conventionally enforces mutual exclusion for those shared variables.

Alternatively, a field may be declared `volatile`, in which case a thread must reconcile its working copy of the field with the master copy every time it accesses the variable. Moreover, operations on the master copies of one or more volatile variables on behalf of a thread are performed by the main memory in exactly the order that the thread requested. A `final` field cannot also be declared `volatile`.

### 2.9.2 Initialization of Fields

If a field declaration contains a variable initializer, then it has the semantics of an assignment to the declared variable, and:

- If the declaration is for a class variable (that is, a `static` field), then the variable initializer is evaluated and the assignment performed exactly once, when the class is initialized (§2.17.4).

- If the declaration is for an instance variable (that is, a field that is not `static`), then the variable initializer is evaluated and the assignment performed each time an instance of the class is created.

## 2.10 Methods

A method declares executable code that can be invoked, passing a fixed number of values as arguments. Every method declaration belongs to some class. A class inherits from its direct superclass (§2.8.3) and any direct superinterfaces (§2.13.2) all the accessible methods of the superclass and superinterfaces, with one exception: if a name is declared as a method in the new class, then no method with the same signature (§2.10.2) is inherited. Instead, the newly declared method is said to override any such method declaration. An overriding method must not conflict with the definition that it overrides, for instance, by having a different return type. Overridden methods of the superclass can be accessed using a method invocation expression involving the `super` keyword.

### 2.10.1 Formal Parameters

The formal parameters of a method, if any, are specified by a list of comma-separated parameter specifiers. Each parameter specifier consists of a type and an identifier that specifies the name of the parameter. When the method is invoked, the values of the actual argument expressions initialize newly created parameter variables (§2.5), each of the declared type, before execution of the body of the method.

A method parameter of type float always contains an element of the float value set (§2.4.3); similarly, a method parameter of type double always contains an element of the double value set. It is not permitted for a method parameter of type float to contain an element of the float-extended-exponent value set that is not also an element of the float value set, nor for a method parameter of type double to contain an element of the double-extended-exponent value set that is not also an element of the double value set.

Where an actual argument expression corresponding to a parameter variable is not FP-strict (§2.18), evaluation of that actual argument expression is permitted to use values drawn from the appropriate extended-exponent value sets. Prior to being stored in the parameter variable, the result of such an expression is mapped to the nearest value in the corresponding standard value set by method invocation conversion (§2.6.8).

### 2.10.2 Method Signature

The signature of a method consists of the name of the method and the number and type of formal parameters (§2.10.1) of the method. A class may not declare two methods with the same signature.

### 2.10.3 Method Modifiers

The access modifiers `public`, `protected`, and `private` are discussed in Section 2.7.4.

An `abstract` method declaration introduces the method as a member, providing its signature (§2.10.2), return type, and `throws` clause (if any), but does not provide an implementation. The declaration of an `abstract` method m must appear within an `abstract` class (call it A). Every subclass of A that is not itself `abstract` must provide an implementation for m. A method declared `abstract` cannot also be declared to be `private`, `static`, `final`, `native`, `strictfp`, or `synchronized`.

A method that is declared `static` is called a class method. A class method is always invoked without reference to a particular object. A class method may refer to other fields and methods of the class by simple name only if they are class methods and class (`static`) variables.

A method that is not declared `static` is an instance method. An instance method is always invoked with respect to an object, which becomes the current object to which the keywords `this` and `super` refer during execution of the method body.

A method can be declared `final` to prevent subclasses from overriding or hiding it. A `private` method and all methods declared in a `final` class (§2.8.2) are implicitly `final`, because it is impossible to override them. If a method is `final` or implicitly `final`, a compiler or a runtime code generator can safely "inline" the body of a `final` method, replacing an invocation of the method with the code in its body.

A `synchronized` method will acquire a monitor lock (§2.19) before it executes. For a class (`static`) method, the lock associated with the class object for the method's class is used. For an instance method, the lock associated with `this` (the object for which the method is invoked) is used. The same per-object lock is used by the `synchronized` statement.

A method can be declared `strictfp` to indicate that all expressions in the method are FP-strict (§2.18).

A method can be declared `native` to indicate that it is implemented in platform-dependent code, typically written in another programming language such as C, C++, or assembly language. A method may not be declared to be both `native` and `strictfp`.

## 2.11 Static Initializers

Any static initializers declared in a class are executed when the class is initialized (§2.17.4) and, together with any field initializers (§2.9.2) for class variables, may be used to initialize the class variables of the class (§2.17.4).

The static initializers and class variable initializers are executed in textual order. They may not refer to class variables declared in the class whose declarations appear textually after the use, even though these class variables are in scope. This restriction is designed to catch, at compile time, most circular or otherwise malformed initializations.

## 2.12 Constructors

A constructor is used in the creation of an object that is an instance of a class. The constructor declaration looks like a method declaration that has no result type. Constructors are invoked by class instance creation expressions (§2.17.6), by the conversions and concatenations caused by the string concatenation operator `+`, and by explicit constructor invocations from other constructors; they are never invoked by method invocation expressions.

Constructor declarations are not members. They are never inherited and therefore are not subject to hiding or overriding.

If a constructor body does not begin with an explicit constructor invocation and the constructor being declared is not part of the primordial class `Object`, then the constructor body is implicitly assumed by the compiler to begin with a superclass constructor invocation "`super();`", an invocation of the constructor of the direct superclass that takes no arguments.

If a class declares no constructors then a default constructor, which takes no arguments, is automatically provided. If the class being declared is `Object`, then the default constructor has an empty body. Otherwise, the default constructor takes no arguments and simply invokes the superclass constructor with no arguments. If the class is declared `public`, then the default constructor is implicitly given the access modifier `public`. Otherwise, the default constructor has the default access implied by no access modifier (§2.7.4).

A class can be designed to prevent code outside the class declaration from creating instances of the class by declaring at least one constructor, in order to prevent the creation of an implicit constructor, and declaring all constructors to be `private`.

### 2.12.1 Constructor Modifiers

Access to constructors is governed by the access modifiers `public`, `protected`, and `private` (§2.7.4).

A constructor cannot be `abstract`, `static`, `final`, `native`, or `synchronized`. A constructor cannot be declared to be `strictfp`. This difference in the definitions for method modifiers (§2.10.3) and constructor modifiers is an intentional language design choice; it effectively ensures that a constructor is FP-strict (§2.18) if and only if its class is FP-strict, so to speak.

## 2.13 Interfaces

An interface is a reference type whose members are constants and `abstract` methods. This type has no implementation, but otherwise unrelated classes can implement it by providing implementations for its `abstract` methods. Programs can use interfaces to make it unnecessary for related classes to share a common `abstract` superclass or to add methods to `Object`.

An interface may be declared to be a direct extension of one or more other interfaces, meaning that it implicitly specifies all the `abstract` methods and constants of the interfaces it extends, except for any constants that it may hide, and perhaps adds newly declared members of its own.

A class may be declared to directly implement one or more interfaces, meaning that any instance of the class implements all the `abstract` methods specified by that interface. A class necessarily implements all the interfaces that its direct superclasses and direct superinterfaces do. This (multiple) interface inheritance allows objects to support (multiple) common behaviors without sharing any implementation.

A variable whose declared type is an interface type may have as its value a reference to an object that is an instance of any class that is declared to implement the specified interface. It is not sufficient that the class happens to implement all the `abstract` methods of the interface; the class or one of its superclasses must actually be declared to implement the interface, or else the class is not considered to implement the interface.

### 2.13.1 Interface Modifiers

An interface declaration may be preceded by the interface modifiers `public`, `strictfp`, and `abstract`. The access modifier `public` is discussed in (§2.7.4). Every interface is implicitly `abstract`. All members of interfaces are implicitly `public`.

An interface cannot be `final`, because the implementation of such a class could never be completed.

### 2.13.2 Superinterfaces

If an `extends` clause is provided, then the interface being declared extends each of the other named interfaces and therefore inherits the methods and constants of each of the other named interfaces. Any class that `implements` the declared interface is also considered to implement all the interfaces that this interface extends and that are accessible to the class.

The `implements` clause in a class declaration lists the names of interfaces that are direct superinterfaces of the class being declared. All interfaces in the current package are accessible. Interfaces in other packages are accessible if the host system permits access to the package and the interface is declared `public`.

An interface type K is a superinterface of class type C if K is a direct superinterface of C ; or if C has a direct superinterface J that has K as a superinterface; or if K is a superinterface of the direct superclass of C. A class is said to implement all its superinterfaces.

There is no analogue of the class `Object` for interfaces; that is, while every class is an extension of class `Object`, there is no single interface of which all interfaces are extensions.

### 2.13.3 Interface Members

The members of an interface are those members inherited from direct superinterfaces and those members declared in the interface. The interface inherits, from the interfaces it extends, all members of those interfaces, except for fields with the same names as fields it declares. Interface members are either fields or methods.

#### 2.13.3.1 Interface (Constant) Fields

Every field declaration in the body of an interface is implicitly `static` and `final`. Interfaces do not have instance variables. Every field declaration in an interface is itself implicitly `public`. A constant declaration in an interface must not include either of the modifiers `transient` or `volatile`.

Every field in the body of an interface must have an initialization expression, which need not be a constant expression. The variable initializer is evaluated and the assignment performed exactly once, when the interface is initialized (§2.17.4).

#### 2.13.3.2 Interface (Abstract) Methods

Every method declaration in the body of an interface is implicitly `abstract` and implicitly `public`.

A method declared in the body of an interface must not be declared `static`, because `static` methods cannot be `abstract`.

A method declared in the body of an interface must not be declared `native`, `strictfp`, or `synchronized`, because those keywords describe implementation properties rather than interface properties; however, a method declared in an interface may be implemented by a method that is declared `native`, `strictfp`, or `synchronized` in a class that implements the interface. A method declared in the body of an interface must not be declared `final`; however, one may be implemented by a method that is declared `final` in a class that implements the interface.

### 2.13.4 Overriding, Inheritance, and Overloading in Interfaces

If the interface declares a method, then the declaration of that method is said to override any and all methods with the same signature in the superinterfaces of the interface that would otherwise be accessible to code in this interface.

An interface inherits from its direct superinterfaces all methods of the superinterfaces that are not overridden by a method declared in the interface.

If two methods of an interface (whether both are declared in the same interface, or both are inherited by an interface, or one is declared and one is inherited) have the same name but different signatures, then the method name is said to be overloaded.

## 2.14 Nested Classes and Interfaces

JDK release 1.1 added nested classes and interfaces to the Java programming language. Nested classes and interfaces are sometimes referred to as inner classes and interfaces, which are one sort of nested classes and interfaces. However, nested classes and interfaces also encompass nested top-level classes and interfaces, which are not inner classes or interfaces.

A full specification of nested classes and interfaces will be published in the second edition of The JavaTM Language Specification. Until then, interested persons should refer to the Inner Classes Specification, which may be found at `http://java.sun.com/products/jdk/1.1/docs/guide/innerclasses/spec/innerclasses.doc.html`.

## 2.15 Arrays

Arrays are objects, are dynamically created, and may be assigned to variables of type `Object` (§2.4.7). All methods on arrays are inherited from class `Object` except the `clone` method, which arrays override. All arrays implement the interfaces `Cloneable` and `java.io.Serializable`.

An array object contains a number of variables. That number may be zero, in which case the array is said to be empty. The variables contained in an array have no names; instead they are referenced by array access expressions that use nonnegative integer index values. These variables are called the components of the array. If an array has n components, we say n is the length of the array.

An array of zero components is not the same as the null reference (§2.4).

An array component of type float is always an element of the float value set (§2.4.3); similarly, a component of type double is always an element of the double value set. A component of type float may not be an element of the float-extended-exponent value set unless it is also an element of the float value set. A component of type double may not be an element of the double-extended-exponent value set unless it is also an element of the double value set.

### 2.15.1 Array Types

All the components of an array have the same type, called the component type of the array. If the component type of an array is T, then the type of the array itself is written T`[]`.

The component type of an array may itself be an array type. The components of such an array may contain references to subarrays. If, starting from any array type, one considers its component type, and then (if that is also an array type) the component type of that type, and so on, eventually one must reach a component type that is not an array type; this is called the element type of the original array, and the components at this level of the data structure are called the elements of the original array.

There are three situations in which an element of an array can be an array: if the element type is of type `Object` (§2.4.7), `Cloneable`, or `java.io.Serializable`, then some or all of the elements may be arrays, because every array object can be assigned to a variable of one of those types.

In the Java programming language, unlike in C, an array of `char` is not a `String` (§2.4.7), and neither a `String` nor an array of `char` is terminated by `'\u0000'` (the `NUL`-character). A `String` object is immutable (its value never changes), while an array of `char` has mutable elements.

The element type of an array may be any type, whether primitive or reference. In particular, arrays with an interface type as the component type are supported; the elements of such an array may have as their value a null reference or instances of any class type that implements the interface. Arrays with an `abstract` class type as the component type are supported; the elements of such an array may have as their value a null reference or instances of any subclass of this `abstract` class that is not itself `abstract`.

### 2.15.2 Array Variables

A variable of array type holds a reference to an object. Declaring a variable of array type does not create an array object or allocate any space for array components. It creates only the variable itself, which can contain a reference to an array.

Because an array's length is not part of its type, a single variable of array type may contain references to arrays of different lengths. Once an array object is created, its length never changes. To make an array variable refer to an array of different length, a reference to a different array must be assigned to the variable.

If an array variable v has type A`[]`, where A is a reference type, then v can hold a reference to any array type B`[]`, provided B can be assigned to A (§2.6.7).

### 2.15.3 Array Creation

An array is created by an array creation expression or an array initializer.

### 2.15.4 Array Access

A component of an array is accessed using an array access expression. Arrays may be indexed by `int` values; `short`, `byte`, or `char` values may also be used as they are subjected to unary numeric promotion (§2.6.10) and become `int` values.

All arrays are 0-origin. An array with length n can be indexed by the integers 0 through n - 1. All array accesses are checked at run time; an attempt to use an index that is less than zero or greater than or equal to the length of the array causes an `ArrayIndexOutOfBoundsException` to be thrown.

## 2.16 Exceptions

When a program violates the semantic constraints of the Java programming language, the Java virtual machine signals this error to the program as an exception. An example of such a violation is an attempt to index outside the bounds of an array. The Java programming language specifies that an exception will be thrown when semantic constraints are violated and will cause a nonlocal transfer of control from the point where the exception occurred to a point that can be specified by the programmer. An exception is said to be thrown from the point where it occurred and is said to be caught at the point to which control is transferred. A method invocation that completes because an exception causes transfer of control to a point outside the method is said to complete abruptly.

Programs can also throw exceptions explicitly, using `throw` statements. This provides an alternative to the old-fashioned style of handling error conditions by returning distinguished error values, such as the integer value `-1`, where a negative value would not normally be expected.

Every exception is represented by an instance of the class `Throwable` or one of its subclasses; such an object can be used to carry information from the point at which an exception occurs to the handler that catches it. Handlers are established by `catch` clauses of `try` statements. During the process of throwing an exception, the Java virtual machine abruptly completes, one by one, any expressions, statements, method and constructor invocations, static initializers, and field initialization expressions that have begun but not completed execution in the current thread. This process continues until a handler is found that indicates that it handles the thrown exception by naming the class of the exception or a superclass of the class of the exception. If no such handler is found, then the method `uncaughtException` is invoked for the `ThreadGroup` that is the parent of the current thread.

In the Java programming language the exception mechanism is integrated with the synchronization model (§2.19) so that locks are properly released as `synchronized` statements and so that invocations of `synchronized` methods complete abruptly.

The specific exceptions covered in this section are that subset of the predefined exceptions that can be thrown directly by the operation of the Java virtual machine. Additional exceptions can be thrown by class library or user code; these exceptions are not covered here. See The JavaTM Language Specification for information on all predefined exceptions.

### 2.16.1 The Causes of Exceptions

An exception is thrown for one of three reasons:

1. An abnormal execution condition was synchronously detected by the Java virtual machine. These exceptions are not thrown at an arbitrary point in the program, but rather at a point where they are specified as a possible result of an expression evaluation or statement execution, such as:

   - When an operation violates the normal semantics of the Java programming language, for example indexing outside the bounds of an array.

   - When an error occurs in loading or linking part of the program.

   - When some limit on a resource is exceeded, for example when too much memory is used.

2. A `throw` statement was executed.

3. An asynchronous exception occurred because:

   - The `stop` method of class `Thread` or `ThreadGroup` was invoked, or

   - An internal error occurred in the virtual machine implementation.

Exceptions are represented by instances of the class `Throwable` and instances of its subclasses. These classes are, collectively, the exception classes.

### 2.16.2 Handling an Exception

When an exception is thrown, control is transferred from the code that caused the exception to the nearest dynamically enclosing `catch` clause of a `try` statement that handles the exception.

A statement or expression is dynamically enclosed by a `catch` clause if it appears within the `try` block of the `try` statement of which the `catch` clause is a part, or if the caller of the statement or expression is dynamically enclosed by the `catch` clause.

The caller of a statement or expression depends on where it occurs:

- If within a method, then the caller is the method invocation expression that was executed to cause the method to be invoked.

- If within a constructor or the initializer for an instance variable, then the caller is the class instance creation expression or the method invocation of `newInstance` that was executed to cause an object to be created.

- If within a static initializer or an initializer for a `static` variable, then the caller is the expression that used the class or interface so as to cause it to be initialized.

Whether a particular `catch` clause handles an exception is determined by comparing the class of the object that was thrown to the declared type of the parameter of the `catch` clause. The `catch` clause handles the exception if the type of its parameter is the class of the exception or a superclass of the class of the exception. Equivalently, a `catch` clause will catch any exception object that is an `instanceof` the declared parameter type.

The control transfer that occurs when an exception is thrown causes abrupt completion of expressions and statements until a `catch` clause is encountered that can handle the exception; execution then continues by executing the block of that `catch` clause. The code that caused the exception is never resumed.

If no `catch` clause handling an exception can be found, then the current thread (the thread that encountered the exception) is terminated, but only after all `finally` clauses have been executed and the method `uncaughtException` has been invoked for the `ThreadGroup` that is the parent of the current thread.

In situations where it is desirable to ensure that one block of code is always executed after another, even if that other block of code completes abruptly, a `try` statement with a `finally` clause may be used. If a `try` or `catch` block in a `try-finally` or `try-catch-finally` statement completes abruptly, then the `finally` clause is executed during propagation of the exception, even if no matching `catch` clause is ultimately found. If a `finally` clause is executed because of abrupt completion of a `try` block and the `finally` clause itself completes abruptly, then the reason for the abrupt completion of the `try` block is discarded and the new reason for abrupt completion is propagated from there.

Most exceptions occur synchronously as a result of an action by the thread in which they occur and at a point in the program that is specified to possibly result in such an exception. An asynchronous exception is, by contrast, an exception that can potentially occur at any point in the execution of a program.

Asynchronous exceptions are rare. They occur only as a result of:

- An invocation of the `stop` method of class `Thread` or `ThreadGroup`.

- An internal error in the Java virtual machine implementation.

A `stop` method may be invoked by one thread to affect another thread or all the threads in a specified thread group. It is asynchronous because it may occur at any point in the execution of the other thread or threads. An internal error is considered asynchronous so that it may be handled using the same mechanism that handles the `stop` method, as will now be described.

The Java programming language permits a small but bounded amount of execution to occur before an asynchronous exception is thrown. This delay is permitted to allow optimized code to detect and throw these exceptions at points where it is practical to handle them while obeying the semantics of the language.

A simple implementation might poll for asynchronous exceptions at the point of each control transfer instruction. Since a program has a finite size, this provides a bound on the total delay in detecting an asynchronous exception. Since no asynchronous exception will occur between control transfers, the code generator has some flexibility to reorder computation between control transfers for greater performance.

All exceptions in the Java programming language are precise: when the transfer of control takes place, all effects of the statements executed and expressions evaluated before the point from which the exception is thrown must appear to have taken place. No expressions, statements, or parts thereof that occur after the point from which the exception is thrown may appear to have been evaluated. If optimized code has speculatively executed some of the expressions or statements which follow the point at which the exception occurs, such code must be prepared to hide this speculative execution from the user-visible state of the program.

### 2.16.3 The Exception Hierarchy

The possible exceptions in a program are organized in a hierarchy of classes, rooted at class `Throwable`, a direct subclass of `Object`. The classes `Exception` and `Error` are direct subclasses of `Throwable`. The class `RuntimeException` is a direct subclass of `Exception`.

Programs can use the preexisting exception classes in `throw` statements, or define additional exception classes as subclasses of `Throwable` or of any of its subclasses, as appropriate. To take advantage of compile-time checking for exception handlers, it is typical to define most new exception classes as checked exception classes, specifically as subclasses of `Exception` that are not subclasses of `RuntimeException`.

### 2.16.4 The Classes `Exception` and `RuntimeException`

The class `Exception` is the superclass of all the standard exceptions that ordinary programs may wish to recover from.

The class `RuntimeException` is a subclass of class `Exception`. The subclasses of `RuntimeException` are unchecked exception classes. The package `java.lang` defines the following standard unchecked runtime exceptions:

- `ArithmeticException`: An exceptional arithmetic situation has arisen, such as an integer division or integer remainder operation with a zero divisor.

- `ArrayStoreException`: An attempt has been made to store into an array component a value whose class is not assignment compatible with the component type of the array.

- `ClassCastException`: An attempt has been made to cast a reference to an object to an inappropriate type.

- `IllegalMonitorStateException`: A thread has attempted to wait on or notify other threads waiting on an object that it has not locked.

- `IndexOutOfBoundsException`: Either an index of some sort (such as to an array, a string, or a vector) or a subrange, specified either by two index values or by an index and a length, was out of range.

- `NegativeArraySizeException`: An attempt was made to create an array with a negative length.

- `NullPointerException`: An attempt was made to use a null reference in a case where an object reference was required.

- `SecurityException`: A security violation was detected.

The class `Error` and its standard subclasses are exceptions from which ordinary programs are not ordinarily expected to recover. The class `Error` is a separate subclass of `Throwable`, distinct from `Exception` in the class hierarchy, in order to allow programs to use the idiom

            } catch (Exception e) {

to catch all exceptions from which recovery may be possible without catching errors from which recovery is typically not possible. Package `java.lang` defines all the error classes described here.

The Java virtual machine throws an object that is an instance of a subclass of `LinkageError` when a loading (§2.17.2), linking (§2.17.3), or initialization (§2.17.4) error occurs.

- The loading process is described in (§2.17.2). The errors `ClassFormatError`, `ClassCircularityError`, `NoClassDefFoundError`, and `UnsupportedClassVersionError` are described there.

- The linking process is described in (§2.17.3). The linking errors `NoSuchFieldError`, `NoSuchMethodError`, `InstantiationError`, and `IllegalAccessError` are described there.

- The class verification process is described in (§2.17.3). The verification failure error `VerifyError` is described there.

- The class initialization process is described in (§2.17.4). A virtual machine will throw the error `ExceptionInInitializerError` if execution of a static initializer or of an initializer for a `static` field (§2.11) results in an exception that is not an `Error` or a subclass of `Error`.

  A `LinkageError` may also be thrown at run time:

- An `AbstractMethodError` is thrown at run time if an `abstract` method is invoked.

- An `UnsatisfiedLinkError` is thrown at run time if the Java virtual machine cannot find an appropriate definition of a method declared to be `native`.

A Java virtual machine implementation throws an object that is an instance of a subclass of the class `VirtualMachineError` when an internal error or resource limitation prevents it from implementing the semantics of the Java programming language. This specification defines the following virtual machine errors:

- `InternalError`: An internal error has occurred in the Java virtual machine implementation because of a fault in the software implementing the virtual machine, a fault in the underlying host system software, or a fault in the hardware. This error is delivered asynchronously when it is detected and may occur at any point in a program.

- `OutOfMemoryError`: The Java virtual machine implementation has run out of either virtual or physical memory, and the automatic storage manager was unable to reclaim enough memory to satisfy an object creation request.

- `StackOverflowError`: The Java virtual machine implementation has run out of stack space for a thread, typically because the thread is doing an unbounded number of recursive invocations as a result of a fault in the executing program.

- `UnknownError`: An exception or error has occurred, but the Java virtual machine implementation is unable to report the actual exception or error.

## 2.17 Execution

This section specifies activities that occur during execution of a program. It is organized around the life cycle of the Java virtual machine and of the classes, interfaces, and objects that form a program. It specifies the detailed procedures used in starting up the virtual machine (§2.17.1), class and interface type loading (§2.17.2), linking (§2.17.3), and initialization (§2.17.4). It then specifies the procedures for creation of new class instances (§2.17.6). It concludes by describing the unloading of classes (§2.17.8) and the procedure followed when a virtual machine exits (§2.17.9).

### 2.17.1 Virtual Machine Start-up

The Java virtual machine starts execution by invoking the method `main` of some specified class and passing it a single argument, which is an array of strings. This causes the specified class to be loaded (§2.17.2), linked (§2.17.3) to other types that it uses, and initialized (§2.17.4). The method `main` must be declared `public`, `static`, and `void`.

The manner in which the initial class is specified to the Java virtual machine is beyond the scope of this specification, but it is typical, in host environments that use command lines, for the fully qualified name of the class to be specified as a command-line argument and for subsequent command-line arguments to be used as strings to be provided as the argument to the method `main`. For example, using Sun's Java 2 SDK for Solaris, the command line

        java Terminator Hasta la vista Baby!

will start a Java virtual machine by invoking the method `main` of class `Terminator` (a class in an unnamed package) and passing it an array containing the four strings `"Hasta"`, `"la"`, `"vista"`, and `"Baby!"`.

We now outline the steps the virtual machine may take to execute `Terminator`, as an example of the loading, linking, and initialization processes that are described further in later sections.

The initial attempt to execute the method `main` of class `Terminator` discovers that the class `Terminator` is not loaded-that is, the virtual machine does not currently contain a binary representation for this class. The virtual machine then uses a `ClassLoader` (§2.17.2) to attempt to find such a binary representation. If this process fails, an error is thrown. This loading process is described further in (§2.17.2).

After `Terminator` is loaded, it must be initialized before `main` can be invoked, and a type (class or interface) must always be linked before it is initialized. Linking (§2.17.3) involves verification, preparation, and (optionally) resolution.

Verification (§2.17.3) checks that the loaded representation of `Terminator` is well formed, with a proper symbol table. Verification also checks that the code that implements `Terminator` obeys the semantic requirements of the Java virtual machine. If a problem is detected during verification, an error is thrown.

Preparation (§2.17.3) involves allocation of static storage and any data structures that are used internally by the virtual machine, such as method tables.

Resolution (§2.17.3) is the process of checking symbolic references from class `Terminator` to other classes and interfaces, by loading the other classes and interfaces that are mentioned and checking that the references are correct.

The resolution step is optional at the time of initial linkage. An implementation may resolve a symbolic reference from a class or interface that is being linked very early, even to the point of resolving all symbolic references from the classes and interfaces that are further referenced, recursively. (This resolution may result in errors from further loading and linking steps.) This implementation choice represents one extreme and is similar to the kind of static linkage that has been done for many years in simple implementations of the C language.

An implementation may instead choose to resolve a symbolic reference only when it is actually used; consistent use of this strategy for all symbolic references would represent the "laziest" form of resolution. In this case, if `Terminator` had several symbolic references to another class, the references might be resolved one at a time or perhaps not at all, if these references were never used during execution of the program.

The only requirement regarding when resolution is performed is that any errors detected during resolution must be thrown at a point in the program where some action is taken by the program that might, directly or indirectly, require linkage to the class or interface involved in the error. In the "static" example implementation choice described earlier, loading and linking errors could occur before the program is executed if they involved a class or interface mentioned in the class `Terminator` or any of the further, recursively referenced classes and interfaces. In a system that implemented the "laziest" resolution, these errors would be thrown only when a symbolic reference was used.

In our running example, the virtual machine is still trying to execute the method `main` of class `Terminator`. This is permitted only if the class has been initialized (§2.17.4).

Initialization consists of execution of any class variable initializers and static initializers of the class `Terminator`, in textual order. But before `Terminator` can be initialized, its direct superclass must be initialized, as well as the direct superclass of its direct superclass, and so on, recursively. In the simplest case, `Terminator` has `Object` as its implicit direct superclass; if class `Object` has not yet been initialized, then it must be initialized before `Terminator` is initialized.

If class `Terminator` has another class `Super` as its superclass, then `Super` must be initialized before `Terminator`. This requires loading, verifying, and preparing `Super`, if this has not already been done, and, depending on the implementation, may also involve resolving the symbolic references from `Super` and so on, recursively.

Initialization may thus cause loading, linking, and initialization errors, including such errors involving other types.

Finally, after completion of the initialization for class `Terminator` (during which other consequential loading, linking, and initializing may have occurred), the method `main` of `Terminator` is invoked.

### 2.17.2 Loading

Loading refers to the process of finding the binary form of a class or interface type with a particular name, perhaps by computing it on the fly, but more typically by retrieving a binary representation previously computed from source code by a compiler and constructing, from that binary form, a `Class` object to represent the class or interface. The binary format of a class or interface is normally the `class` file format (see Chapter 4, "The class File Format").

The loading process is implemented by the class `ClassLoader` and its subclasses. Different subclasses of `ClassLoader` may implement different loading policies. In particular, a class loader may cache binary representations of classes and interfaces, prefetch them based on expected usage, or load a group of related classes together. These activities may not be completely transparent to a running application if, for example, a newly compiled version of a class is not found because an older version is cached by a class loader. It is the responsibility of a class loader, however, to reflect loading errors only at points in the program where they could have arisen without prefetching or group loading.

If an error occurs during class loading, then an instance of one of the following subclasses of class `LinkageError` will be thrown at any point in the program that (directly or indirectly) uses the type:

- `ClassFormatError`: The binary data that purports to specify a requested compiled class or interface is malformed.

- `UnsupportedClassVersionError`: A class or interface could not be loaded because it is represented using an unsupported version of the `class` file format.3

- `ClassCircularityError`: A class or interface could not be loaded because it would be its own superclass or superinterface (§2.13.2).

- `NoClassDefFoundError`: No definition for a requested class or interface could be found by the relevant class loader.

### 2.17.3 Linking: Verification, Preparation, and Resolution

Linking is the process of taking a binary form of a class or interface type and combining it into the runtime state of the Java virtual machine, so that it can be executed. A class or interface type is always loaded before it is linked. Three different activities are involved in linking: verification, preparation, and resolution of symbolic references.

The Java programming language allows an implementation flexibility as to when linking activities (and, because of recursion, loading) take place, provided that the semantics of the language are respected, that a class or interface is completely verified and prepared before it is initialized, and that errors detected during linkage are thrown at a point in the program where some action is taken by the program that might require linkage to the class or interface involved in the error.

For example, an implementation may choose to resolve each symbolic reference in a class or interface individually, only when it is used (lazy or late resolution), or to resolve them all at once, for example, while the class is being verified (static resolution). This means that the resolution process may continue, in some implementations, after a class or interface has been initialized.

Verification ensures that the binary representation of a class or interface is structurally correct. For example, it checks that every instruction has a valid operation code; that every branch instruction branches to the start of some other instruction, rather than into the middle of an instruction; that every method is provided with a structurally correct signature; and that every instruction obeys the type discipline of the Java programming language.

If an error occurs during verification, then an instance of the following subclass of class `LinkageError` will be thrown at the point in the program that caused the class to be verified:

- `VerifyError`: The binary definition for a class or interface failed to pass a set of required checks to verify that it cannot violate the integrity of the Java virtual machine.

Preparation involves creating the static fields for a class or interface and initializing such fields to the standard default values (§2.5.1). This does not require the execution of any Java virtual machine code; explicit initializers for static fields are executed as part of initialization (§2.17.4), not preparation.

Implementations of the Java virtual machine may precompute additional data structures at preparation time in order to make later operations on a class or interface more efficient. One particularly useful data structure is a "method table" or other data structure that allows any method to be invoked on instances of a class without requiring a search of superclasses at invocation time.

The binary representation of a class or interface references other classes and interfaces and their fields, methods, and constructors symbolically, using the fully qualified names (§2.7.5) of the other classes and interfaces. For fields and methods these symbolic references include the name of the class or interface type that declares the field or method, as well as the name of the field or method itself, together with appropriate type information.

Before a symbolic reference can be used it must undergo resolution, wherein a symbolic reference is validated and, typically, replaced with a direct reference that can be more efficiently processed if the reference is used repeatedly.

If an error occurs during resolution, then an instance of one of the following subclasses of class `IncompatibleClassChangeError`, or of some other subclass, or of `IncompatibleClassChangeError` itself (which is a subclass of the class `LinkageError`) may be thrown at any point in the program that uses a symbolic reference to the type:

- `IllegalAccessError`: A symbolic reference has been encountered that specifies a use or assignment of a field, or invocation of a method, or creation of an instance of a class to which the code containing the reference does not have access because the field or method was declared `private`, `protected`, or default access (not `public`), or because the class was not declared `public`. This can occur, for example, if a field that is originally declared `public` is changed to be `private` after another class that refers to the field has been compiled.

- `InstantiationError`: A symbolic reference has been encountered that is used in a class instance creation expression, but an instance cannot be created because the reference turns out to refer to an interface or to an `abstract` class. This can occur, for example, if a class that is originally not `abstract` is changed to be `abstract` after another class that refers to the class in question has been compiled.

- `NoSuchFieldError`: A symbolic reference has been encountered that refers to a specific field of a specific class or interface, but the class or interface does not declare a field of that name. This can occur, for example, if a field declaration was deleted from a class after another class that refers to the field was compiled.

- `NoSuchMethodError`: A symbolic reference has been encountered that refers to a specific method of a specific class or interface, but the class or interface does not declare a method of that name and signature. This can occur, for example, if a method declaration was deleted from a class after another class that refers to the method was compiled.

### 2.17.4 Initialization

Initialization of a class consists of executing its static initializers (§2.11) and the initializers for static fields (§2.9.2) declared in the class. Initialization of an interface consists of executing the initializers for fields declared in the interface (§2.13.3.1).

Before a class or interface is initialized, its direct superclass must be initialized, but interfaces implemented by the class need not be initialized. Similarly, the superinterfaces of an interface need not be initialized before the interface is initialized.

A class or interface type T will be initialized immediately before one of the following occurs:

- T is a class and an instance of T is created.

- T is a class and a static method of T is invoked.

- A nonconstant static field of T is used or assigned. A constant field is one that is (explicitly or implicitly) both `final` and `static`, and that is initialized with the value of a compile-time constant expression. A reference to such a field must be resolved at compile time to a copy of the compile-time constant value, so uses of such a field never cause initialization.

Invocation of certain methods in library classes (§3.12) also causes class or interface initialization. See the Java 2 platform's class library specifications (for example, class `Class` and package `java.lang.reflect`) for details.

The intent here is that a type have a set of initializers that put it in a consistent state and that this state be the first state that is observed by other classes. The static initializers and class variable initializers are executed in textual order and may not refer to class variables declared in the class whose declarations appear textually after the use, even though these class variables are in scope. This restriction is designed to detect, at compile time, most circular or otherwise malformed initializations.

Before a class or interface is initialized its superclass is initialized, if it has not previously been initialized.

### 2.17.5 Detailed Initialization Procedure

Initialization of a class or interface requires careful synchronization, since some other thread may be trying to initialize the same class or interface at the same time. There is also the possibility that initialization of a class or interface may be requested recursively as part of the initialization of that class or interface; for example, a variable initializer in class A might invoke a method of an unrelated class B, which might in turn invoke a method of class A. The implementation of the Java virtual machine is responsible for taking care of synchronization and recursive initialization by using the following procedure. It assumes that the `Class` object has already been verified and prepared and that the `Class` object contains state that can indicate one of four situations:

- This `Class` object is verified and prepared but not initialized.

- This `Class` object is being initialized by some particular thread T.

- This `Class` object is fully initialized and ready for use.

- This `Class` object is in an erroneous state, perhaps because the verification step failed or because initialization was attempted and failed.

The procedure for initializing a class or interface is then as follows:

1. Synchronize on the `Class` object that represents the class or interface to be initialized. This involves waiting until the current thread can obtain the lock for that object (§8.13).

2. If initialization by some other thread is in progress for the class or interface, then `wait` on this `Class` object (which temporarily releases the lock). When the current thread awakens from the `wait`, repeat this step.

3. If initialization is in progress for the class or interface by the current thread, then this must be a recursive request for initialization. Release the lock on the `Class` object and complete normally.

4. If the class or interface has already been initialized, then no further action is required. Release the lock on the `Class` object and complete normally.

5. If the `Class` object is in an erroneous state, then initialization is not possible. Release the lock on the `Class` object and throw a `NoClassDefFoundError`.

6. Otherwise, record the fact that initialization of the `Class` object is now in progress by the current thread and release the lock on the `Class` object.

7. Next, if the `Class` object represents a class rather than an interface, and the direct superclass of this class has not yet been initialized, then recursively perform this entire procedure for the uninitialized superclass. If the initialization of the direct superclass completes abruptly because of a thrown exception, then lock this `Class` object, label it erroneous, notify all waiting threads, release the lock, and complete abruptly, throwing the same exception that resulted from the initializing the superclass.

8. Next, execute either the class variable initializers and static initializers of the class or the field initializers of the interface, in textual order, as though they were a single block, except that `final` `static` variables and fields of interfaces whose values are compile-time constants are initialized first.

9. If the execution of the initializers completes normally, then lock this `Class` object, label it fully initialized, notify all waiting threads, release the lock, and complete this procedure normally.

10. Otherwise, the initializers must have completed abruptly by throwing some exception E. If the class of E is not `Error` or one of its subclasses, then create a new instance of the class `ExceptionInInitializerError`, with E as the argument, and use this object in place of E in the following step. But if a new instance of `ExceptionInInitializerError` cannot be created because an `OutOfMemoryError` occurs, then instead use an `OutOfMemoryError` object in place of E in the following step.

11. Lock the `Class` object, label it erroneous, notify all waiting threads, release the lock, and complete this procedure abruptly with reason E or its replacement as determined in the previous step.

In some early implementations of the Java virtual machine, an exception during class initialization was ignored rather than allowing it to cause an `ExceptionInInitializerError` as described here.

### 2.17.6 Creation of New Class Instances

A new class instance is explicitly created when one of the following situations occurs:

- Evaluation of a class instance creation expression creates a new instance of the class whose name appears in the expression.

- Invocation of the `newInstance` method of class `Class` creates a new instance of the class represented by the `Class` object for which the method was invoked.

A new class instance may be implicitly created in the following situations:

- Loading of a class or interface that contains a `String` literal may create a new `String` object (§2.4.8) to represent that literal. This may not occur if the a `String` object has already been created to represent a previous occurrence of that literal, or if the `String.intern` method has been invoked on a `String` object representing the same string as the literal.

- Execution of a string concatenation operator that is not part of a constant expression sometimes creates a new `String` object to represent the result. String concatenation operators may also create temporary wrapper objects for a value of a primitive type (§2.4.1).

Each of these situations identifies a particular constructor to be called with specified arguments (possibly none) as part of the class instance creation process.

Whenever a new class instance is created, memory space is allocated for it with room for all the instance variables declared in the class type and all the instance variables declared in each superclass of the class type, including all the instance variables that may be hidden. If there is not sufficient space available to allocate memory for the object, then creation of the class instance completes abruptly with an `OutOfMemoryError`. Otherwise, all the instance variables in the new object, including those declared in superclasses, are initialized to their default values (§2.5.1).

Just before a reference to the newly created object is returned as the result, the indicated constructor is processed to initialize the new object using the following procedure:

1. Assign the arguments for the constructor to newly created parameter variables for this constructor invocation.

2. If this constructor begins with an explicit constructor invocation of another constructor in the same class (using `this`), then evaluate the arguments and process that constructor invocation recursively using these same five steps. If that constructor invocation completes abruptly, then this procedure completes abruptly for the same reason. Otherwise, continue with step 5.

3. If this constructor does not begin with an explicit constructor invocation of another constructor in the same class (using `this`) and is in a class other than `Object`, then this constructor will begin with an explicit or implicit invocation of a superclass constructor (using `super`). Evaluate the arguments and process that superclass constructor invocation recursively using these same five steps. If that constructor invocation completes abruptly, then this procedure completes abruptly for the same reason. Otherwise, continue with step 4.

4. Execute the instance variable initializers for this class, assigning their values to the corresponding instance variables, in the left-to-right order in which they appear textually in the source code for the class. If execution of any of these initializers results in an exception, then no further initializers are processed and this procedure completes abruptly with that same exception. Otherwise, continue with step 5. (In some early implementations, the compiler incorrectly omitted the code to initialize a field if the field initializer expression was a constant expression whose value was equal to the default initialization value for its type. This was a bug.)

5. Execute the rest of the body of this constructor. If that execution completes abruptly, then this procedure completes abruptly for the same reason. Otherwise, this procedure completes normally.

Unlike C++, the Java programming language does not specify altered rules for method dispatch during the creation of a new class instance. If methods are invoked that are overridden in subclasses in the object being initialized, then these overriding methods are used, even before the new object is completely created.

### 2.17.7 Finalization of Class Instances

The class `Object` has a `protected` method called `finalize`; this method can be overridden by other classes. The particular definition of `finalize` that can be invoked for an object is called the finalizer of that object. Before the storage for an object is reclaimed by the garbage collector, the Java virtual machine will invoke the finalizer of that object.

Finalizers provide a chance to free up resources (such as file descriptors or operating system graphics contexts) that cannot be freed automatically by an automatic storage manager. In such situations, simply reclaiming the memory used by an object would not guarantee that the resources it held would be reclaimed.

The Java programming language does not specify how soon a finalizer will be invoked, except to say that it will happen before the storage for the object is reused. Nor does the language specify which thread will invoke the finalizer for any given object. If an uncaught exception is thrown during the finalization, the exception is ignored and finalization of that object terminates.

The `finalize` method declared in class `Object` takes no action. However, the fact that class `Object` declares a `finalize` method means that the `finalize` method for any class can always invoke the `finalize` method for its superclass, which is usually good practice. (Unlike constructors, finalizers do not automatically invoke the finalizer for the superclass; such an invocation must be coded explicitly.)

For efficiency, an implementation may keep track of classes that do not override the `finalize` method of class `Object` or that override it in a trivial way, such as

        protected void finalize() { super.finalize(); }

We encourage implementations to treat such objects as having a finalizer that is not overridden and to finalize them more efficiently.

The `finalize` method may be invoked explicitly, just like any other method. However, doing so does not have any effect on the object's eventual automatic finalization.

The Java virtual machine imposes no ordering on `finalize` method calls. Finalizers may be called in any order or even concurrently.

As an example, if a circularly linked group of unfinalized objects becomes unreachable, then all the objects may become finalizable together. Eventually, the finalizers for these objects may be invoked in any order or even concurrently using multiple threads. If the automatic storage manager later finds that the objects are unreachable, then their storage can be reclaimed.

### 2.17.8 Unloading of Classes and Interfaces

A class or interface may be unloaded if and only if its class loader is unreachable. The bootstrap class loader is always reachable; as a result, system classes may never be unloaded.

### 2.17.9 Virtual Machine Exit

The Java virtual machine terminates all its activity and exits when one of two things happens:

- All the threads that are not daemon threads (§2.19) terminate.

- Some thread invokes the `exit` method of class `Runtime` or class `System`, and the exit operation is permitted by the security manager.

A program can specify that all finalizers that have not been automatically invoked are to be run before the virtual machine exits. This is done by invoking the method `runFinalizersOnExit` of the class `System` with the argument `true`.4 By default finalizers are not run on exit. Once running finalizers on exit has been enabled it may be disabled by invoking `runFinalizersOnExit` with the argument `false`. An invocation of the `runFinalizersOnExit` method is permitted only if the caller is allowed to `exit` and is otherwise rejected by the security manager.

## 2.18 FP-strict Expressions

If the type of an expression is float or double, then there is a question as to what value set (§2.4.3) the value of the expression may be drawn from. This is governed by the rules of value set conversion (§2.6.6); these rules in turn depend on whether or not the expression is FP-strict.

Every compile-time constant expression is FP-strict. If an expression is not a compile-time constant expression, then consider all the class declarations, interface declarations, and method declarations that contain the expression. If any such declaration bears the strictfp modifier, then the expression is FP-strict.

It follows that an expression is not FP-strict if and only if it is not a compile-time constant expression and it does not appear within any declaration that has the strictfp modifier.

Within an FP-strict expression, all intermediate values must be elements of the float value set or the double value set, implying that the results of all FP-strict expressions must be those predicted by IEEE 754 arithmetic on operands represented using single and double formats. Within an expression that is not FP-strict, some leeway is granted for an implementation to use an extended exponent range to represent intermediate results; the net effect, roughly speaking, is that a calculation might produce "the correct answer" in situations where exclusive use of the float value set or double value set might result in overflow or underflow.

## 2.19 Threads

While most of the preceding discussion is concerned only with the behavior of code as executed by a single thread, the Java virtual machine can support many threads of execution at once. These threads independently execute code that operates on values and objects residing in a shared main memory. Threads may be supported by having many hardware processors, by time-slicing a single hardware processor, or by time-slicing many hardware processors.

Any thread may be marked as a daemon thread. When code running in some thread creates a new `Thread` object, that new thread is initially marked as a daemon thread if and only if the creating thread is a daemon thread. A program can change whether or not a particular thread is a daemon thread by calling the `setDaemon` method in class `Thread`. The Java virtual machine initially starts up with a single nondaemon thread, which typically calls the method `main` of some class. The virtual machine may also create other daemon threads for internal purposes. The Java virtual machine exits when all nondaemon threads have terminated (§2.17.9).

By providing mechanisms for synchronizing the concurrent activity of threads, the Java programming language supports the coding of programs that, though concurrent, still exhibit deterministic behavior. To synchronize threads the language uses monitors, a mechanism for allowing one thread at a time to execute a region of code. The behavior of monitors is explained in terms of locks. There is a lock associated with each object.

The `synchronized` statement performs two special actions relevant only to multithreaded operation:

1. After computing a reference to an object but before executing its body, it locks a lock associated with the object.

2. After execution of the body has completed, either normally or abruptly, it unlocks that same lock. As a convenience, a method may be declared `synchronized`; such a method behaves as if its body were contained in a `synchronized` statement.

The methods `wait`, `notify`, and `notifyAll` of class `Object` support an efficient transfer of control from one thread to another. Rather than simply "spinning" (repeatedly locking and unlocking an object to see whether some internal state has changed), which consumes computational effort, a thread can suspend itself using `wait` until such time as another thread awakens it using `notify` or `notifyAll`. This is especially appropriate in situations where threads have a producer-consumer relationship (actively cooperating on a common goal) rather than a mutual exclusion relationship (trying to avoid conflicts while sharing a common resource).

As a thread executes code, it carries out a sequence of actions. A thread may use the value of a variable or assign it a new value. (Other actions include arithmetic operations, conditional tests, and method invocations, but these do not involve variables directly.) If two or more concurrent threads act on a shared variable, there is a possibility that the actions on the variable will produce timing-dependent results. This dependence on timing is inherent in concurrent programming and produces one of the few situations where the result of a program is not determined solely by The JavaTM Language Specification.

Each thread has a working memory, in which it may keep copies of the values of variables from the main memory that are shared between all threads. To access a shared variable, a thread usually first obtains a lock and flushes its working memory. This guarantees that shared values will thereafter be loaded from the shared main memory to the working memory of the thread. By unlocking a lock, a thread guarantees that the values held by the thread in its working memory will be written back to the main memory.

The interaction of threads with the main memory, and thus with each other, may be explained in terms of certain low-level actions. There are rules about the order in which these actions may occur. These rules impose constraints on any implementation of the Java programming language. A programmer may rely on the rules to predict the possible behaviors of a concurrent program. The rules do, however, intentionally give the implementor certain freedoms. The intent is to permit certain standard hardware and software techniques that can greatly improve the speed and efficiency of concurrent code.

Briefly put, the important consequences of the rules are the following:

- Proper use of synchronization constructs will allow reliable transmission of values or sets of values from one thread to another through shared variables.

- When a thread uses the value of a variable, the value it obtains is in fact a value stored into the variable by that thread or by some other thread. This is true even if the program does not contain code for proper synchronization. For example, if two threads store references to different objects into the same reference value, the variable will subsequently contain a reference to one object or the other, not a reference to some other object or a corrupted reference value. (There is a special exception for `long` and `double` values; see §8.4.)

- In the absence of explicit synchronization, an implementation is free to update the main memory in an order that may be surprising. Therefore, the programmer who prefers to avoid surprises should use explicit synchronization.

The details of the interaction of threads with the main memory, and thus with each other, are discussed in detail in Chapter 8, "Threads and Locks."

1 Including updates for JDK release 1.1 and the Java 2 platform, v1.2, published at `http://java.sun.com`.

2 Note that a local variable is not initialized on its creation and is considered to hold a value only once it is assigned (§2.5.1).

3 `UnsupportedClassVersionError`, a subclass of `ClassFormatError`, was introduced in the Java 2 platform, v1.2, to enable easy identification of a `ClassFormatError` caused by an attempt to load a class represented using an unsupported version of the `class` file format.

4 The method `runFinalizersOnExit` was first implemented in JDK release 1.1 but has been deprecated in the Java 2 platform, v1.2.

Contents | Prev | Next | Index

The JavaTM Virtual Machine Specification
Copyright © 1999 Sun Microsystems, Inc. All rights reserved
Please send any comments or corrections to jvm@java.sun.com