Java Source-to-Execution Lifecycle

1Concept / Definition

The Java source-to-execution lifecycle is the path a program takes from human-readable source code to machine instructions running on a CPU. It is split into two halves that happen at different times, usually on different machines.

• Compile time. javac reads .java files, checks them against the language rules, and writes platform-neutral bytecode into .class files, normally packaged into a JAR.
• Run time. A JVM on the target machine loads the classes it needs, verifies them, links and initialises them, then executes the bytecode — first by interpreting it, then by compiling frequently used code to native instructions with the just-in-time (JIT) compiler.

2Why It Exists

A single compilation step straight to machine code, as in C, ties the binary to one operating system and CPU. Java deliberately splits the work so that each half can do what it is best placed to do.

3Core Concepts

.java source files

A source file is plain text containing one or more type declarations. Its structure and naming follow simple rules that javac enforces:

• At most one public top-level type per file, and the file must be named after it: public class Order lives in Order.java.
• The package declaration should match the directory structure: package com.shop.order; lives in com/shop/order/. Build tools and the class loader rely on this.
• Source files are read as UTF-8 by default since Java 18, so the platform's default encoding no longer changes how source is compiled.
• Java 25 compact source files (JEP 512) are an exception: a file with only methods and fields, and a void main(), is treated as an implicitly declared class. See 2.1.

Compilation with javac

javac turns source into bytecode in a series of phases. It parses text into a syntax tree, resolves names and types, checks flow rules such as definite assignment and unreachable code, lowers language features into simpler constructs, and finally writes class files.

Most of the compiler's work is checking, not optimising. javac performs only simple optimisations such as folding compile-time constants; almost all performance optimisation happens later in the JIT. Several language features exist only at compile time: generic type arguments are erased, enhanced for loops become iterator or index loops, and auto-boxing becomes calls such as Integer.valueOf.

.class files

Each class, interface, enum and record produces its own .class file, including nested types: Order$Item.class for a nested class and Order$1.class for an anonymous class. A class file is a precisely specified binary structure defined in the JVMS.

The constant pool is the symbol table of the class: every class name, method signature, field reference and literal used by the code is stored once there and referred to by index. The major version records which Java release the class targets; a JVM refuses to load classes newer than itself.

Bytecode

Bytecode is the instruction set of the JVM. Each instruction is one byte of opcode followed by optional operands, which gives about two hundred possible instructions. The JVM is a stack machine: instructions push values onto an operand stack, pop them to compute results, and store them into numbered local-variable slots. There are no CPU registers in the model; mapping to registers is the job of the JIT.

Class loading

The JVM does not load an entire application at startup. It loads a class the first time the class is needed, in three phases: loading reads the bytes and creates a Class object; linking verifies the bytecode, allocates static fields with default values and resolves symbolic references; initialisation runs static initialisers and static field assignments.

Class loaders form a hierarchy. The bootstrap loader loads the core platform modules such as java.base; the platform loader loads other Java SE and JDK modules; the application loader loads your classes from the class path or module path. Each loader first delegates to its parent, so a core class such as java.lang.String is always loaded by the bootstrap loader and cannot be replaced by an application class of the same name.

Initialisation is triggered by the first active use of a class: creating an instance, calling a static method, reading or writing a non-constant static field, initialising a subclass, reflective access, or being the main class. Merely declaring a variable of the type does not initialise the class.

JVM execution

Execution starts with the main method on the main thread. Every thread has its own stack of frames; each method call pushes a frame containing its local-variable slots and operand stack, and each return pops it. Objects live on the shared heap; class metadata lives in metaspace; compiled native code lives in the code cache.

Interpretation

When a method is first called, HotSpot runs it in the interpreter. The interpreter executes bytecode instruction by instruction using prebuilt machine-code templates, so code can start running immediately. While interpreting, it also counts method invocations and loop iterations, and records profiles: which branches are taken, which receiver types appear at call sites. These counters and profiles drive the JIT.

JIT compilation

When a method becomes "hot", HotSpot compiles it to native code. Modern HotSpot uses tiered compilation with two compilers. C1 compiles quickly with light optimisation and inserts profiling. C2 compiles the hottest code later with aggressive optimisation based on the collected profile: inlining, escape analysis, loop optimisation, dead-code elimination and speculative optimisations such as assuming only one receiver type at a call site.

Speculative optimisations can become invalid — for example, when a new subclass is loaded and a previously single-type call site becomes polymorphic. The JVM then deoptimises: it discards the compiled code and returns to the interpreter until the method is recompiled. Long-running loops can also be switched to compiled code mid-execution through on-stack replacement (OSR).

Program lifecycle

A Java process has a clear lifecycle from the java command to the exit code returned to the operating system.

The JVM shuts down when the last non-daemon thread ends, when System.exit() is called, or when the process receives a termination signal such as SIGTERM. It then runs registered shutdown hooks and exits. A forced kill (SIGKILL, kill -9) terminates the process immediately and skips the hooks, which matters for graceful shutdown in containers.

4How It Works Internally

Following one small program end to end ties the concepts together.

package com.example;

public class Calculator {
    public static void main(String[] args) {
        int a = 10;
        int b = 20;
        int sum = a + b;
        System.out.println(sum);
    }
}

1. javac checks the file, resolves System.out and println(int), and writes com/example/Calculator.class with major version 69.
2. java com.example.Calculator starts the launcher, which creates the JVM. The bootstrap loader has already loaded core classes such as String, System and PrintStream from the modules image.
3. The application loader loads Calculator, the verifier checks its bytecode, and linking prepares it. As the main class, it is initialised immediately.
4. The JVM invokes main on the main thread. The interpreter executes the bytecode below. The first getstatic resolves the constant-pool reference to System.out into a direct reference.
5. main returns, the main thread ends, no non-daemon threads remain, and the JVM shuts down with exit code 0.

public static void main(java.lang.String[]);
  Code:
     0: bipush        10
     2: istore_1
     3: bipush        20
     5: istore_2
     6: iload_1
     7: iload_2
     8: iadd
     9: istore_3
    10: getstatic     #7   // Field java/lang/System.out:Ljava/io/PrintStream;
    13: iload_3
    14: invokevirtual #13  // Method java/io/PrintStream.println:(I)V
    17: return

This program is far too short for the JIT to matter. In a real service, the same methods run millions of times: they move from interpreter to C1 to C2 within seconds or minutes, which is the warm-up curve shown in section 3.

5APIs / Features / Syntax

# Training run: exercise the application, then exit; the cache is written
$ java -XX:AOTCacheOutput=app.aot -jar app.jar

# Production runs start from the cache
$ java -XX:AOTCache=app.aot -jar app.jar

6Practical Examples

Example 1 — Compile and run a packaged program

$ tree src
src
└── com/example/Calculator.java
$ javac -d out src/com/example/Calculator.java
$ tree out
out
└── com/example/Calculator.class
$ java -cp out com.example.Calculator
30

The package com.example becomes the directory com/example in both the source and output trees, and the class is run by its fully qualified name, not its file path.

Example 2 — Watch class loading

$ java -Xlog:class+load -cp out com.example.Calculator | grep -v "shared"
[0.041s][info][class,load] com.example.Calculator source: file:/home/dev/out/
30

Hundreds of JDK classes are loaded before Calculator, most of them from the class data sharing archive. Filtering them out shows the one application class and where it came from — useful when diagnosing which JAR a class was actually loaded from.

Example 3 — Lazy initialisation and the constant trap

public class InitOrder {

    static {
        System.out.println("1. InitOrder initialised (main class)");
    }

    public static void main(String[] args) {
        System.out.println("2. main starts");
        System.out.println("3. constant = " + Config.CONSTANT);
        System.out.println("4. started set = " + (Config.STARTED > 0));
    }
}

class Config {
    static final int CONSTANT = 42;                // compile-time constant
    static final long STARTED = System.nanoTime(); // computed at run time

    static {
        System.out.println("   Config initialised");
    }
}

1. InitOrder initialised (main class)
2. main starts
3. constant = 42
   Config initialised
4. started set = true

Reading Config.CONSTANT does not initialise Config, because javac copied the constant value 42 directly into InitOrder's bytecode. Reading Config.STARTED is an active use of a non-constant field, so Config is initialised at that moment. The same rule means that changing a public constant in a library does not change callers until they are recompiled.

Example 4 — See the JIT at work

public class HotLoop {
    static long total(int n) {
        long sum = 0;
        for (int i = 0; i < n; i++) sum += i % 7;
        return sum;
    }

    public static void main(String[] args) {
        long result = 0;
        for (int round = 0; round < 20_000; round++) result += total(1_000);
        System.out.println(result);
    }
}

$ java -XX:+PrintCompilation HotLoop | grep HotLoop
     63   81       3       HotLoop::total (26 bytes)
     66   84 %     4       HotLoop::total @ 7 (26 bytes)
     67   85       4       HotLoop::total (26 bytes)
     68   81       3       HotLoop::total (26 bytes)   made not entrant

Read the columns as time in milliseconds, compile ID, flags (% marks on-stack replacement), tier and method. total is compiled first at tier 3 (C1 with profiling), then its loop is replaced on the stack by C2 code, then the whole method is compiled at tier 4 (C2). The old tier-3 version is then "made not entrant": no new calls use it.

Example 5 — Graceful shutdown hook

public class Worker {
    public static void main(String[] args) throws InterruptedException {
        Runtime.getRuntime().addShutdownHook(Thread.ofPlatform().unstarted(() -> {
            System.out.println("Shutdown hook: flushing buffers, closing pools");
        }));
        System.out.println("Working... press Ctrl+C or send SIGTERM");
        Thread.sleep(60_000);
    }
}

Ctrl+C or SIGTERM runs the hook before the JVM exits. kill -9 does not. In Kubernetes, the container receives SIGTERM first and SIGKILL only after the grace period, so shutdown hooks — or framework shutdown callbacks built on them — must finish inside that window.

7Common Problems & Mistakes

8Performance & Production Considerations

• Warm-up and autoscaling. A freshly started instance runs slower until its hot paths are compiled. If a load balancer sends full traffic to it immediately, latency spikes. Use readiness checks, gradual traffic shifting, or synthetic warm-up requests.
• Startup time. Class data sharing is on by default for JDK classes. Application CDS archives and the Java 25 AOT cache extend it to application classes and profiles, often reducing startup noticeably without code changes.
• CPU limits in containers. The JIT compiler threads compete with application threads for CPU. A container limited to one CPU warms up much more slowly than one with two or more; very small CPU limits hurt JIT-heavy services the most.
• Graceful shutdown. Configure the framework's graceful shutdown, keep the orchestrator's grace period longer than it, and never depend on hooks for data that must not be lost.
• Code cache. Very large applications can fill the code cache, after which the JIT stops compiling and performance degrades. It is rare, but visible with jcmd Compiler.codecache and in JVM logs.

9Architecture & Design Considerations

The lifecycle creates a trade-off between fast startup and high peak throughput. Different deployment styles value these differently, and the platform now offers several ways to shift the balance.

10Interview Questions & Answers

Key Takeaways

• Java is compiled twice: to bytecode by javac, and hot code to native instructions by the JIT at run time.
• Class files carry a version (Java 25 = 69), a constant pool and bytecode for a stack machine.
• Classes load lazily through a parent-first loader hierarchy: loading, linking (verify, prepare, resolve), initialisation.
• Interpretation gives instant start; tiered C1/C2 compilation gives peak speed after warm-up; deoptimisation keeps speculation safe.
• Startup versus peak throughput is an architectural trade-off: CDS/AOT cache, native image or standard JIT, chosen by scaling pattern.

Coverage checklist

.java source files ✔ · Compilation with javac ✔ · .class files ✔ · Bytecode ✔ · Class loading ✔ · JVM execution ✔ · Interpretation ✔ · JIT compilation ✔ · Program lifecycle ✔