.JAVA File Format – Execution and initialisation

Start-up and main

The JVM starts by loading, linking and initialising a main class chosen by the launcher (java com.example.App, the Main-Class of a JAR, or the first class of a source file run with java App.java), then calls its main method (JLS 12.1).

A candidate main method is a method named main that is not private, returns void, and has either one parameter of type String[] (or String...) or no parameters (JLS 12.1.4, Java 25):

• If the class declares or inherits a candidate with a String[] parameter, that one is used; otherwise the one with no parameters.
• For an instance main, the launcher creates an object of the class with its constructor without parameters, which must not be private, and calls main on it.
• Before Java 25, only public static void main(String[]) was recognised (from Java 21 to 24 the other forms were a preview feature).

Loading and linking

A class is identified at run time by its binary name together with its defining class loader, so the same class file loaded by two loaders gives two distinct classes.

Class initialisation

Initialising a class runs its static initialisers and static field initialisers, in the order they appear in the source. A class is initialised just before the first of these (JLS 12.4.1):

• an instance of it is created;
• one of its static methods is called;
• one of its static fields is assigned, or used when it is not a constant variable;
• reflection asks for it, as with Class.forName("…");
• a subclass is initialised, or it is the main class.

Before a class is initialised, its superclass is, and so are those of its superinterfaces that declare default methods. Using a constant variable, such as Integer.MAX_VALUE, does not initialise its class, since the value was copied in at compile time. Neither does using a class literal or declaring a variable of the type.

• Initialisation is thread-safe: the JVM locks the class so that only one thread runs the initialisers, and others wait. This makes the holder class idiom a safe lazy singleton.
• If an initialiser throws, the exception is wrapped in ExceptionInInitializerError (unless it is already an Error), and the class is marked erroneous: every later attempt to use it throws NoClassDefFoundError.
• A cycle of classes that use each other while initialising can see default values: a thread that is already initialising a class may use it before it is finished.

class Config {
    private Config() { }
    private static class Holder {                 // initialised on first call of get()
        static final Config INSTANCE = new Config();
    }
    static Config get() { return Holder.INSTANCE; }
}

Object creation

For new C(args), the steps are (JLS 12.5):

1. Memory is allocated for all fields of C and its superclasses, set to their default values. If there is no memory, OutOfMemoryError is thrown.
2. The arguments are evaluated and the chosen constructor is entered.
3. If the constructor starts with, or contains after a prologue, this(…), its prologue runs and then the other constructor runs these steps from step 2; afterwards the epilogue runs and creation is complete.
4. Otherwise the prologue runs (Java 25: statements before super(…)), then the superclass constructor, explicit or implicit, runs these steps for the superclass, up to Object.
5. The instance initialisers and instance field initialisers of C run, in textual order.
6. The rest of the constructor body (the epilogue) runs.

An overridden method called from a superclass constructor runs before the subclass’s field initialisers, and sees their default values. Since Java 25 a subclass can avoid this by assigning its fields in the prologue, before super(…).

class Base {
    Base() { describe(); }
    void describe() { }
}
class Derived extends Base {
    String name = "derived";
    @Override void describe() { System.out.println(name); }
}
new Derived();      // prints "null": name is assigned after Base() returns

Finalisation and unloading

Object.finalize() was called by the garbage collector before an object was reclaimed (JLS 12.6). Finalisation has been deprecated for removal since Java 18 (JEP 421), and can be turned off with --finalization=disabled; use try-with-resources and java.lang.ref.Cleaner instead. A class or interface may be unloaded when its defining class loader is unreachable; classes loaded by the bootstrap loader are never unloaded (JLS 12.7).

Program exit

A program exits when every thread that is not a daemon thread has ended, or when Runtime.exit (System.exit) is called (JLS 12.8). The exit status is the value passed to exit, or 0 if the threads ended normally; the java launcher returns 1 when main ends with an uncaught exception. Shutdown hooks run on exit; Runtime.halt stops at once without running them.

Binary compatibility

Classes are compiled separately, so a library may change after code that uses it was compiled. A change is binary compatible if code compiled against the old version still links and runs without recompiling (JLS chapter 13). Some common cases: