What happens when a Java program starts?

Hook: Think of Java startup like opening night at a theater: the building powers on, the cast is checked in, and only then does the lead actor step onto the stage.

Question: What happens when a Java program starts?

Answer: When you run java MyClass, the Java launcher starts the JVM, finds your main class, loads it, and prepares it to run. Before main executes, the JVM initializes that class, which means static fields and static blocks run first. Then it calls public static void main(String[] args) on the main thread and passes your command-line arguments as an array.

Interview-Ready Answer: “When a Java program starts, the java launcher starts the JVM, the JVM locates and loads the class with main, initializes that class, and then invokes public static void main(String[] args) on the main thread. A useful detail is that my application classes are usually loaded by the application class loader, while core JDK classes come from the bootstrap loader. Also, Java loads classes lazily, so only the classes I actually touch get initialized.”

Big picture

“Program start” in Java means more than just jumping into your code. The JVM has to be created, the main class has to be found, the bytecode has to be checked, and the first call to main has to happen. After that, your own code may create more threads, objects, and classes. One important mental model: startup is mostly a chain of finding, checking, and initializing, not immediately “running everything in the project.”

Startup flow under the hood

1. The operating system launches the java executable. That native launcher parses command-line options like heap size, class path, or module path.
2. The launcher starts the JVM and creates the initial runtime structures: the heap for objects, one stack per thread, metadata storage for classes (Metaspace in HotSpot), and the code cache where JIT-compiled code is stored later.
3. The JVM locates the main class or main module. With older style apps, it uses the class path; with modular apps, it uses the module path.
4. The class loader finds the bytecode for that class. The bootstrap class loader loads core JDK classes, the platform class loader loads JDK platform modules, and the application class loader usually loads your app code.
5. The JVM loads the class, then links it. Linking means verification (the bytecode is structurally safe), preparation (memory is allocated for static fields with default values), and resolution (symbolic references are turned into direct references).
6. The JVM initializes the class. This is when static field initializers and static blocks run, in source order. If one of them throws an exception, startup can fail with ExceptionInInitializerError.
7. Finally, the JVM invokes public static void main(String[] args). The args array is never null; if no arguments were passed, it is empty.
8. After main starts, your code may create objects and threads. Hot methods may later be compiled by the JIT compiler, which improves performance after startup rather than before it.

Load vs link vs initialize

Important details interviewers like

• Lazy loading: Java does not load every class in the project at startup. It loads classes when they are first needed, which keeps startup smaller but can move work later.
• Main class initialization: The class that contains main is initialized before main runs. Nested helper classes are often not loaded until you touch them.
• Static constants gotcha: Reading a compile-time constant such as static final int may not trigger class initialization because the compiler can inline the value.
• Performance: Startup cost is roughly proportional to the number of classes loaded and initialized. A tiny command-line program may start in tens of milliseconds on a warm machine, while a large framework app can take hundreds of milliseconds or several seconds, especially if it scans packages or opens network connections during initialization.
• Failure path: If the main class cannot be found, if the main method signature is wrong, or if static initialization fails, the JVM stops before your business logic really begins.

When and why this matters

You care about startup when building CLIs, serverless functions, containers, or microservices, because startup time affects cold starts and deployment readiness. You also care when debugging weird failures, because a problem in a static block can prevent the app from ever reaching main.

Real-world story

Imagine a checkout service in an e-commerce system. On startup, it reads configuration, connects to metrics, initializes a database pool, and registers HTTP routes. If a developer puts a database connection in a static initializer because it “runs before main,” the service may crash before it can even log a helpful message.

What goes wrong: the container starts, then immediately restarts in a loop. Logs show ExceptionInInitializerError or NoClassDefFoundError: Could not initialize class ..., readiness probes never pass, and customers see checkout timeouts or 503s. The bug is not in the business logic; it is in startup-time side effects that should have been delayed until after the app is ready.

Follow-up & Tricky Questions:

• What is the difference between class loading and initialization? Loading finds the bytecode and creates the class inside the JVM; initialization runs static field initializers and static blocks. A class can be loaded without being initialized if nothing actively uses it yet.
• What thread runs main? The JVM starts the application’s main thread and invokes main there. If your program needs concurrency, it must create its own worker threads or use an executor.
• What happens if the main method signature is wrong? The launcher fails before your code runs, because it looks for exactly public static void main(String[] args) or an equivalent varargs form. A similar method with the wrong visibility, return type, or parameters will not be used as the entry point.
• What if a static initializer throws an exception? Class initialization fails, and the first access often shows ExceptionInInitializerError. Later attempts may surface NoClassDefFoundError because the class could not be initialized successfully.
• Why don’t all classes load at startup? Java loads classes lazily to keep startup and memory usage lower. Only the classes needed for the current execution path are loaded and initialized.
• Does args ever come in as null? In normal Java application startup, no: the launcher passes a non-null array, and it is empty when there are no arguments. A null check is usually unnecessary, though checking args.length is still common.
• Does accessing static final int initialize the class? Not necessarily. If it is a compile-time constant, the value can be inlined into callers, so the JVM may not need to initialize that class just to read the value.
• Can a program start without main? A standard Java SE application launched with java needs a valid entry point. Frameworks may hide the main method from you, but somewhere in the startup chain a real main still exists.

Common Mistakes:

• Thinking all classes load at once. Correction: Java loads classes on demand, so only what you touch gets loaded and initialized.
• Confusing loading with initialization. Correction: loading brings in the class; initialization runs the static code.
• Assuming main can have any signature. Correction: the launcher requires the exact entry-point shape, or a compatible varargs form.
• Putting real work in static blocks. Correction: static initialization should be small and safe; heavy work belongs in explicit startup code where you can handle errors cleanly.

Memory Hook: “Find it, check it, wake it up, then call main.” That is the whole startup story in one line.

Cheat Sheet:

• java launcher starts the JVM.
• The JVM finds the class with main.
• Core classes come from the bootstrap loader; your app code usually comes from the application loader.
• Loading, linking, and initialization are separate phases.
• Static fields and static blocks run before main in the main class.
• args is non-null and may be empty.

Practice Tasks:

• Run a tiny class with a static block and observe the order of printed lines.
• Change a field from static final Integer to static final int and see whether accessing it still initializes the class.
• Trigger the failure path by passing missing as an argument and observe the caught ClassNotFoundException.