For example, in a UNIX implementation, the command line:

java Test reboot Bob Dot Enzo

will typically start a Java Virtual Machine by invoking methodmain of classTest (a class in an unnamed package), passing it an array containing the four strings "reboot", "Bob", "Dot", and "Enzo".

The initial attempt to execute the methodmain of classTest discovers that the classTest is not loaded - that is, that the Java Virtual Machine does not currently contain a binary representation for this class. The Java Virtual Machine then uses a class loader to attempt to find such a binary representation. If this process fails, then an error is thrown. This loading process is described further in§12.2.

AfterTest is loaded, it must be initialized beforemain can be invoked. AndTest, like all classes and interfaces, must be linked before it is initialized. Linking involves verification, preparation, and (optionally) resolution. Linking is described further in§12.3.

Verification checks that the loaded representation ofTest is well-formed, with a proper symbol table. Verification also checks that the code that implementsTest obeys the semantic requirements of the Java programming language and the Java Virtual Machine. If a problem is detected during verification, then an error is thrown. Verification is described further in§12.3.1.

Preparation involves allocation of static storage and any data structures that are used internally by the implementation of the Java Virtual Machine, such as method tables. Preparation is described further in§12.3.2.

Resolution is the process of checking symbolic references fromTest 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 symbolic references 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 these 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. (In these implementations, a compiled program is typically represented as an "a.out" file that contains a fully-linked version of the program, including completely resolved links to library routines used by the program. Copies of these library routines are included in the "a.out" file.)

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

The only requirement on 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. Using the "static" example implementation choice described above, loading and linkage errors could occur before the program is executed if they involved a class or interface mentioned in the classTest 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 an incorrect symbolic reference is actively used.

The resolution process is described further in§12.3.3.

In our continuing example, the Java Virtual Machine is still trying to execute the methodmain of classTest. This is permitted only if the class has been initialized (§12.4.1).

Initialization consists of execution of any class variable initializers and static initializers of the classTest, in textual order. But beforeTest 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,Test hasObject as its implicit direct superclass; if classObject has not yet been initialized, then it must be initialized beforeTest is initialized. ClassObject has no superclass, so the recursion terminates here.

If classTest has another classSuper as its superclass, thenSuper must be initialized beforeTest. This requires loading, verifying, and preparingSuper if this has not already been done and, depending on the implementation, may also involve resolving the symbolic references fromSuper and so on, recursively.

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

The initialization process is described further in§12.4.

Finally, after completion of the initialization for classTest (during which other consequential loading, linking, and initializing may have occurred), the methodmain ofTest is invoked.

The methodmain must be declaredpublic,static, andvoid. It must specify a formal parameter (§8.4.1) whose declared type is array ofString. Therefore, either of the following declarations is acceptable:

public static void main(String[] args)

public static void main(String... args)

The loading process is implemented by the classClassLoader and its subclasses. The methoddefineClass of classClassLoader may be used to constructClass objects from binary representations in theclass file format (§1.4).

Different subclasses ofClassLoader 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 classLinkageError will be thrown at any point in the program that (directly or indirectly) uses the requested class or interface:

Because loading involves the allocation of new data structures, it may fail with anOutOfMemoryError.

Well-behaved class loaders maintain these properties:

A malicious class loader could violate these properties. However, it could not undermine the security of the type system, because the Java Virtual Machine guards against this.

For further discussion of these issues, seeThe Java Virtual Machine Specification, Java SE 24 Edition and the paperDynamic Class Loading in the Java Virtual Machine, by Sheng Liang and Gilad Bracha, inProceedings of OOPSLA '98, published asACM SIGPLAN Notices, Volume 33, Number 10, October 1998, pages 36-44. A basic principle of the design of the Java programming language is that the run-time type system cannot be subverted by code written in the Java programming language, not even by implementations of sensitive system classes such asClassLoader.

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 Virtual Machine.

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

Preparation involves creating thestatic fields (class variables and constants) for a class or interface and initializing such fields to the default values (§4.12.5). This does not require the execution of any source code; explicit initializers for static fields are executed as part of initialization (§12.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 binary names (§13.1) of the other classes and interfaces. For fields and methods, these symbolic references include the name of the class or interface of which the field or method is a member, 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 checked to be correct 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 error will be thrown. Most typically, this will be an instance of one of the following subclasses of the classIncompatibleClassChangeError, but it may also be an instance of some other subclass ofIncompatibleClassChangeError or even an instance of the classIncompatibleClassChangeError itself. This error may be thrown at any point in the program that uses a symbolic reference, directly or indirectly:

Additionally, anUnsatisfiedLinkError, a subclass ofLinkageError, may be thrown if a class declares anative method for which no implementation can be found. The error will occur if the method is used, or earlier, depending on what kind of resolution strategy is being used by an implementation of the Java Virtual Machine (§12.3).

A class or interfaceT will be initialized immediately before the first occurrence of any one of the following:

When a class is initialized, its superclasses are initialized (if they have not been previously initialized), as well as any superinterfaces (§8.1.5) that declare any default methods (§9.4.3) (if they have not been previously initialized). Initialization of an interface does not, of itself, cause initialization of any of its superinterfaces.

A reference to astatic field (§8.3.1.1) causes initialization of only the class or interface that actually declares it, even though it might be referred to through the name of a subclass, a subinterface, or a class that implements an interface.

Invocation of certain reflective methods in classClass and in packagejava.lang.reflect also causes class or interface initialization.

A class or interface will not be initialized under any other circumstance.

Note that a compiler may generatesynthetic default methods in an interface, that is, default methods that are neither explicitly nor implicitly declared (§13.1). Such methods will trigger the interface's initialization despite the source code giving no indication that the interface should be initialized.

The intent is that a class or interface has a set of initializers that put it in a consistent state, and that this state is 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 (§8.3.3). This restriction is designed to detect, at compile time, most circular or otherwise malformed initializations.

The fact that initialization code is unrestricted allows examples to be constructed where the value of a class variable can be observed when it still has its initial default value, before its initializing expression is evaluated, but such examples are rare in practice. (Such examples can be also constructed for instance variable initialization (§12.5).) The full power of the Java programming language is available in these initializers; programmers must exercise some care. This power places an extra burden on code generators, but this burden would arise in any case because the Java programming language is concurrent (§12.4.2).

class Super {    static { System.out.print("Super "); }}class One {    static { System.out.print("One "); }}class Two extends Super {    static { System.out.print("Two "); }}class Test {    public static void main(String[] args) {        One o = null;        Two t = new Two();        System.out.println((Object)o == (Object)t);    }}

Super Two false

class Super {    static int taxi = 1729;}class Sub extends Super {    static { System.out.print("Sub "); }}class Test {    public static void main(String[] args) {        System.out.println(Sub.taxi);    }}

1729

interface I {    int i = 1, ii = Test.out("ii", 2);}interface J extends I {    int j = Test.out("j", 3), jj = Test.out("jj", 4);}interface K extends J {    int k = Test.out("k", 5);}class Test {    public static void main(String[] args) {        System.out.println(J.i);        System.out.println(K.j);    }    static int out(String s, int i) {        System.out.println(s + "=" + i);        return i;    }}

1j=3jj=43

Because the Java programming language is multithreaded, 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 classA might invoke a method of an unrelated classB, which might in turn invoke a method of classA. The implementation of the Java Virtual Machine is responsible for taking care of synchronization and recursive initialization by using the following procedure.

The procedure assumes that theClass object has already been verified and prepared, and that theClass object contains state that indicates one of four situations:

For each class or interfaceC, there is a unique initialization lockLC. The mapping fromC toLC is left to the discretion of the Java Virtual Machine implementation. The procedure for initializingC is then as follows:

An implementation may optimize this procedure by eliding the lock acquisition in step 1 (and release in step 4/5) when it can determine that the initialization of the class has already completed, provided that, in terms of the memory model, all happens-before orderings that would exist if the lock were acquired, still exist when the optimization is performed.

Code generators need to preserve the points of possible initialization of a class or interface, inserting an invocation of the initialization procedure described above. If this initialization procedure completes normally and theClass object is fully initialized and ready for use, then the invocation of the initialization procedure is no longer necessary and it may be eliminated from the code - for example, by patching it out or otherwise regenerating the code.

Compile-time analysis may, in some cases, be able to eliminate many of the checks that a class or interface has been initialized from the generated code, if an initialization order for a group of related classes and interfaces can be determined. Such analysis must, however, fully account for concurrency and for the fact that initialization code is unrestricted.

• Loading of a class or interface that contains a string literal (§3.10.5) or a text block (§3.10.6) may create a newString object to denote the string represented by the string literal or text block. (This object creation will not occur if an instance ofString denoting the same sequence of Unicode code points as the string represented by the string literal or text block has previously been interned.)

• Execution of an operation that causes boxing conversion (§5.1.7). Boxing conversion may create a new object of a wrapper class (Boolean,Byte,Short,Character,Integer,Long,Float,Double) associated with one of the primitive types.

• Execution of a string concatenation operator+ (§15.18.1) that is not part of a constant expression (§15.29) always creates a newString object to represent the result. String concatenation operators may also create temporary wrapper objects for a value of a primitive type.

• Evaluation of a method reference expression (§15.13.3) or a lambda expression (§15.27.4) may require that a new instance be created of a class that implements a functional interface type (§9.8).

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 (§8.8.7.1) of another constructor in the same class (usingthis), 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. This constructor does not begin with an explicit constructor invocation of another constructor in the same class (usingthis). If this constructor is for a class other thanObject, then this constructor will begin with an explicit or implicit invocation of a superclass constructor (usingsuper). 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 initializers and instance variable initializers for this class, assigning the values of instance variable initializers 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.

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.

Example 12.5-1. Evaluation of Instance Creation

class Point {    int x, y;    Point() { x = 1; y = 1; }}class ColoredPoint extends Point {    int color = 0xFF00FF;}class Test {    public static void main(String[] args) {        ColoredPoint cp = new ColoredPoint();        System.out.println(cp.color);    }}

ColoredPoint() { super(); }

Point() { super(); x = 1; y = 1; }

Object() { }

Example 12.5-2. Dynamic Dispatch During Instance Creation

class Super {    Super() { printThree(); }    void printThree() { System.out.println("three"); }}class Test extends Super {    int three = (int)Math.PI;  // That is, 3    void printThree() { System.out.println(three); }    public static void main(String[] args) {        Test t = new Test();        t.printThree();    }}

03

For example:

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

Every object can be characterized by two attributes: it may bereachable,finalizer-reachable, orunreachable, and it may also beunfinalized,finalizable, orfinalized.

Areachable object is any object that can be accessed in any potential continuing computation from any live thread.

Afinalizer-reachable object can be reached from some finalizable object through some chain of references, but not from any live thread.

Anunreachable object cannot be reached by either means.

Anunfinalized object has never had its finalizer automatically invoked.

Afinalized object has had its finalizer automatically invoked.

Afinalizable object has never had its finalizer automatically invoked, but the Java Virtual Machine may eventually automatically invoke its finalizer.

An objecto is not finalizable until its constructor has invoked the constructor forObject ono and that invocation has completed successfully (that is, without throwing an exception). Every pre-finalization write to a field of an object must be visible to the finalization of that object. Furthermore, none of the pre-finalization reads of fields of that object may see writes that occur after finalization of that object is initiated.

Optimizing transformations of a program can be designed that reduce the number of objects that are reachable to be less than those which would naively be considered reachable. For example, a Java compiler or code generator may choose to set a variable or parameter that will no longer be used tonull to cause the storage for such an object to be potentially reclaimable sooner.

Another example of this occurs if the values in an object's fields are stored in registers. The program may then access the registers instead of the object, and never access the object again. This would imply that the object is garbage. Note that this sort of optimization is only allowed if references are on the stack, not stored in the heap.

class Foo {    private final Object finalizerGuardian = new Object() {        protected void finalize() throws Throwable {            /* finalize outer Foo object */        }    }}

It must be possible for the memory model (§17.4) to decide when it can commit actions that take place in a finalizer. This section describes the interaction of finalization with the memory model.

Each execution has a number ofreachability decision points, labeleddi. Each action eithercomes-before di orcomes-after di. Other than as explicitly mentioned, the comes-before ordering described in this section is unrelated to all other orderings in the memory model.

Ifr is a read that sees a writew andr comes-beforedi, thenw must come-beforedi.

Ifx andy are synchronization actions on the same variable or monitor such thatso(x, y) (§17.4.4) andy comes-beforedi, thenx must come-beforedi.

At each reachability decision point, some set of objects are marked as unreachable, and some subset of those objects are marked as finalizable. These reachability decision points are also the points at which references are checked, enqueued, and cleared according to the rules provided in the API documentation for the packagejava.lang.ref.

The only objects that are considered definitely reachable at a pointdi are those that can be shown to be reachable by the application of these rules:

If an objectX is marked as unreachable atdi, then:

An actiona is an active use ofX if and only if at least one of the following is true:

If an objectX is marked as finalizable atdi, then:

1. All of its non-daemon threads have terminated, and all of the shutdown hooks which consequently were started by the Java Virtual Machine, if any, have terminated.

2. A thread invokedSystem.exit orRuntime.exit, and all of the shutdown hooks which consequently were started by the Java Virtual Machine, if any, have terminated.

3. A thread invokedRuntime.halt. (No shutdown hooks are started in this situation.)

4. The Java Virtual Machine implementation recognized an external event as requesting termination of the Java Virtual Machine, and all of the shutdown hooks which consequently were started by the Java Virtual Machine, if any, have terminated.

   The nature of the event is outside the scope of this specification, but is necessarily something that a Java Virtual Machine implementation can handle reliably. An example is receiving a signal from the operating system.

5. An external event occurred that the Java Virtual Machine implementation cannot handle. (No shutdown hooks are started in this situation.)

   The nature of the event is outside the scope of this specification, but is necessarily something that a Java Virtual Machine implementation cannot recognize or recover from in any way. Examples include a fatal error occurring in the process running the implementation, or power being removed from the computer running the implementation.