{"title":"How Java Works","description":"","content":"The earlier chapter introduced `javac HelloShop.java` and `java HelloShop`. This chapter opens up what happens between those two commands. The path traces a single Java source file from the moment it's saved to the moment the CPU runs it, including why the same `.class` file can run on a Mac, a Linux server, and a Windows laptop without any changes.\n\n---\n\n# The Big Picture\n\nJava's execution pipeline has two halves. The first half is at build time: the compiler turns source code into bytecode. The second half is at run time: the JVM loads that bytecode, checks it, and runs it, mixing interpretation and just-in-time compilation as it goes.\n\nThe full path from source to CPU:\n\n\n```mermaid\nflowchart LR\n SRC[HelloShop.java
Source code]:::primary\n JAVAC[javac
Front-end compiler]:::orange\n BC[HelloShop.class
Bytecode]:::secondary\n CL[Class Loader]:::teal\n VER[Bytecode Verifier]:::teal\n INT[Interpreter]:::orange\n JIT[JIT Compiler]:::orange\n NAT[Native machine code]:::green\n CPU[CPU]:::red\n\n SRC --> JAVAC --> BC --> CL --> VER --> INT\n INT -.hot methods.-> JIT\n JIT --> NAT\n INT --> CPU\n NAT --> CPU\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef secondary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nThe left half (source to `.class`) happens once, at compile time. The right half (everything inside the JVM) happens every time the program runs. The dotted arrow from interpreter to JIT is the key mechanism: bytecode starts running immediately through the interpreter, and methods that run often get promoted to native code in the background.\n\nThe example below walks each stage using a small program from earlier.\n\n\n```java\npublic class HelloShop {\n public static void main(String[] args) {\n String product = \"Wireless Headphones\";\n double price = 49.99;\n System.out.println(\"Welcome! \" + product + \" is $\" + price);\n }\n}\n```\n\n\nThat output is the end of the pipeline. The walkthrough starts at the beginning.\n\n---\n\n# Step 1: Compilation to Bytecode\n\nRunning `javac HelloShop.java` makes the front-end compiler do three things in order:\n\n1. **Parses** the source into a tree of language constructs (classes, methods, expressions).\n2. **Type-checks** every expression. A `String` can't be assigned to a `double`, so the compiler catches that here.\n3. **Emits bytecode** into `HelloShop.class`.\n\nThe output is not machine code. It's bytecode, which is a compact instruction set for an abstract machine called the JVM. Each instruction is one or two bytes (hence the name), and instead of operating on CPU registers, bytecode operates on a per-method **operand stack**: values are pushed onto it, an instruction pops them, computes, and pushes the result back.\n\nThe bytecode can be inspected with `javap`, a tool that ships with the JDK. Running `javap -c HelloShop` on the compiled class prints something like this for `main`:\n\n\n```shell\npublic static void main(java.lang.String[]);\n Code:\n 0: ldc #7 // String Wireless Headphones\n 2: astore_1\n 3: ldc2_w #9 // double 49.99\n 6: dstore_2\n 7: getstatic #11 // Field java/lang/System.out:Ljava/io/PrintStream;\n 10: new #17 // class java/lang/StringBuilder\n ...\n 35: invokevirtual #29 // Method java/io/PrintStream.println:(Ljava/lang/String;)V\n 38: return\n```\n\n\nNo need to read this fluently. `ldc` loads a constant onto the stack, `astore_1` stores a reference into a local variable, and `invokevirtual` calls an instance method. These are JVM instructions, not x86 or ARM instructions. The host CPU has no idea what `invokevirtual` means.\n\nBytecode is portable because it targets a machine that doesn't exist in hardware. Building that abstract machine in software is the JVM's job.\n\n---\n\n# Step 2: Class Loading\n\nThe `.class` file sits on disk until `java HelloShop` is run. At that point, the JVM starts up and a component called the **class loader** finds `HelloShop.class`, reads the bytes, and loads them into memory as a `Class` object the runtime can work with.\n\nClass loading is on-demand. The JVM does not eagerly load every class on the classpath at startup. It loads `HelloShop` because it was requested, then loads `String`, `System`, and `PrintStream` the first time the running code references them.\n\nLoaders are arranged in a hierarchy. The bootstrap loader handles core JDK classes like `String` and `Object`. The platform loader handles standard modules. The application loader handles application code and any libraries on the classpath. Each loader delegates to its parent before trying itself, which prevents application code from accidentally replacing built-in classes.\n\n---\n\n# Step 3: Bytecode Verification\n\nLoading a class doesn't mean trusting it. Before the JVM executes a single instruction, the **bytecode verifier** scans the loaded `.class` file and rejects anything that breaks the rules of the platform. It checks that:\n\n- Every instruction has the right number and types of operands on the stack.\n- Local variables are not read before they're written.\n- Jumps land on valid instruction boundaries, not into the middle of an instruction.\n- Access modifiers are respected (no calling a `private` method from another class).\n- The file format itself is well-formed and the version is supported by this JVM.\n\nIf any check fails, the JVM throws a `VerifyError` and refuses to run the class. This is part of Java's security model: even when a `.class` file comes from a hostile or buggy tool, the JVM will not execute bytecode that could corrupt the runtime.\n\nFor a class just compiled with `javac`, verification is invisible. It only matters when bytecode comes from an untrusted source, or when a bug in code generation produces something malformed.\n\n---\n\n# Step 4: Execution (Interpreter + JIT)\n\nOnce a class is loaded and verified, the JVM starts running its bytecode. Execution is not one strategy but two working together.\n\n### The Interpreter Starts First\n\nThe **interpreter** walks the bytecode one instruction at a time. For each instruction, it figures out what the instruction means and performs the equivalent action on the JVM's operand stack and local variables. It's straightforward and starts running immediately, with no extra warmup.\n\nThe cost is speed. Interpreting an instruction does much more work per step than executing a native CPU instruction. For a program that runs a few lines and exits, this is fine. For anything that loops millions of times, pure interpretation would be slow.\n\n### The JIT Compiler Kicks In\n\nThe **JIT compiler** (just-in-time) solves that problem. While the interpreter runs, the JVM counts how often each method is called and how often each loop body executes. When a method crosses a threshold and becomes a **hot method**, the JIT compiler translates its bytecode into native machine code for the host CPU, in the background, on another thread.\n\nOnce the native version is ready, the JVM switches: future calls to that method skip the interpreter and run the native code directly. The interpreter doesn't go away. Cold methods, called only once or twice, keep running interpreted because compiling them would cost more than it saves.\n\nHotSpot, the most widely used JVM and the one shipped with OpenJDK, uses **tiered compilation** with two compilers internally: the **C1** compiler (also called the client compiler) compiles quickly to get methods to native code fast, and the **C2** compiler (the server compiler) takes longer to produce more aggressively optimized code for the hottest methods. A method can start interpreted, get compiled by C1, and later get recompiled by C2 once it proves it deserves the extra effort.\n\nJIT warmup is real. The first few invocations of a hot method run through the interpreter while the JIT decides whether to compile it. Long-running servers suit this model because they pay the warmup cost once and then run fast for hours. Short-lived command-line tools feel the cost more, since they may exit before the JIT finishes optimizing.\n\n---\n\n# Step 5: Garbage Collection (One Paragraph)\n\nWhile code runs, it creates objects: a `String`, a `StringBuilder`, the array that backs `args`. Each lives on the **heap**, a region of memory the JVM manages. There's no `free` or `delete` call. A background component called the **garbage collector** tracks which objects are still reachable from running code, and periodically reclaims the ones that aren't. The collector pauses application threads briefly during some of its work, which is why GC tuning matters for latency-sensitive systems.\n\n---\n\n# Putting It All Together\n\nThe same pipeline in table form, mapped to visible terminal effects:\n\n\n| Stage | What Happens | What You See |\n| ------------------ | ------------------------------------------------------------------------------------------------------------- | --------------------------------------------- |\n| Compilation | `javac` parses, type-checks, and writes `.class` bytecode | `HelloShop.class` appears in the folder |\n| Class Loading | JVM finds and loads `.class` files on demand, by name | A short pause when `java` starts |\n| Verification | Verifier scans the bytecode and rejects unsafe or malformed code | Silent on valid code, `VerifyError` if broken |\n| Interpretation | Interpreter walks bytecode one instruction at a time | Output begins almost immediately |\n| JIT Compilation | Background threads compile hot methods to native code | Throughput climbs after warmup |\n| Garbage Collection | Reclaims unreachable heap objects in the background | Brief pauses on large heaps |\n\n\n---\n\n# Write Once, Run Anywhere\n\n`HelloShop.class` is a single file. Copy it to a Windows machine, a macOS laptop, and a Linux server. As long as each machine has a compatible JVM installed, `java HelloShop` produces the same output everywhere. No recompiling. No adjustment for the operating system. No rebuild for x86 versus ARM.\n\nThe portability comes from splitting the work. Bytecode is universal because it targets the abstract JVM, not any real CPU. The JVM itself is **not** universal. The JDK ships a different binary for Windows, macOS Intel, macOS Apple Silicon, Linux x86_64, Linux ARM, and so on, and each one knows how to translate the same bytecode into the right native instructions for that platform.\n\nThis connects two earlier ideas. Java is platform-independent, and the JVM is the runtime that executes bytecode. The platform-independence comes from the bytecode format, and the JVM is the platform-specific piece that makes that bytecode runnable on every operating system Java targets.\n\n---\n\n# A Note on AOT\n\nThe pipeline above is the classic Java model: compile to bytecode, then JIT at runtime. A second path has grown in importance for cases where startup time matters.\n\n**Ahead-of-time (AOT) compilation** compiles bytecode straight to native machine code at build time, before the program ever runs. The result is a single native binary that starts almost instantly and uses less memory, with no JIT warmup. The trade-off is that an AOT binary loses some of the runtime profile-driven optimizations the JIT can do, and it's tied to one operating system and CPU architecture, the same way a C++ binary would be.\n\nModern Java offers several options:\n\n- **GraalVM `native-image`** compiles a whole Java application into a standalone native executable. Common for command-line tools and serverless functions where cold start dominates.\n- **Project Leyden** is an in-progress JDK initiative to bring AOT and pre-execution optimizations into the standard JDK with finer control over how much the program is pre-compiled.\n- **`jaotc`** was an earlier experimental AOT tool that shipped briefly with the JDK and has since been removed.\n\nAOT doesn't replace the standard JVM model for most production workloads; long-running servers still benefit more from JIT. Its existence explains why \"Java\" today can mean either \"bytecode running on HotSpot\" or \"a native binary built ahead of time,\" depending on the project.","pageType":"java"}

How Java Works

Get Premium