Java Architecture

Most languages compile directly to machine code — instructions your specific CPU understands. Java takes a different path. It compiles to an intermediate format called bytecode, which runs on a virtual machine (the JVM) instead of directly on hardware. That virtual machine is what gets installed on each platform — and it handles the translation to native machine code itself. This is the secret behind Java's platform independence. Your code doesn't change. The JVM does the heavy lifting of adapting to the underlying OS and hardware.

Java's architecture is built around three layered components. Each one contains the previous: - JVM (Java Virtual Machine) — The engine that executes bytecode. It's the innermost layer. - JRE (Java Runtime Environment) — The JVM plus the standard libraries your program needs to run. If you just want to run Java programs, this is all you need. - JDK (Java Development Kit) — The JRE plus development tools: the compiler (javac), debugger, profiler, and more. If you're writing Java code, you need the JDK. Think of it this way: JVM is the engine, JRE is the car, JDK is the car plus the full mechanic's toolkit.

You write Java code in a .java file. When you compile it using javac (the Java compiler), it doesn't produce machine code. Instead, it produces a .class file containing bytecode — a compact, platform-neutral set of instructions designed specifically for the JVM. This is the first key insight: the compiler's output is not tied to any OS or CPU architecture.

// HelloWorld.java
public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello, World!");
    }
}

// Compile it:
// javac HelloWorld.java  →  produces HelloWorld.class (bytecode)

// Run it:
// java HelloWorld  →  JVM reads the .class file and executes it

When you run a Java program, the JVM's Class Loader kicks in first. It loads the .class files into memory — not all at once, but dynamically, as they're needed. This has three phases: - Loading — Reads the .class file and brings it into the JVM - Linking — Verifies the bytecode is valid and safe, allocates memory for static variables - Initialization — Runs static initializers and assigns values to static fields The class loader also enforces Java's security model — it verifies that bytecode hasn't been tampered with before it ever executes.

Once classes are loaded, the JVM organizes memory into distinct areas: - Method Area — Stores class-level data: method bytecode, field names, static variables - Heap — Where all objects live. This is what the garbage collector manages. - Stack — Each thread gets its own stack. Every method call creates a "frame" with its local variables and return address. When the method returns, the frame is destroyed. - PC Register — Tracks which instruction the current thread is executing - Native Method Stack — Handles calls to native (non-Java) code like C libraries The heap and method area are shared across threads. The stack and PC register are per-thread — which is why Java threads are isolated from each other's local state.

The Execution Engine is the heart of the JVM. It reads bytecode and executes it. It has two modes: Interpreter — Reads and executes bytecode line by line. Simple, but slow for repeated code since it re-translates the same instructions every time. JIT Compiler (Just-In-Time) — The smart part. The JVM monitors which methods are called frequently (called "hot spots"). The JIT compiler compiles those hot methods directly into native machine code and caches the result. Next time that method runs, it executes native code — as fast as C++. This is why Java, despite running on a VM, can match or beat C++ performance in long-running applications. The JVM gets smarter the longer your program runs.

In C or C++, you manually allocate and free memory. Forget to free it, and you have a memory leak. Free it too early, and you crash. Java eliminates this entire class of bugs with automatic garbage collection. The GC runs in the background, identifies objects on the heap that are no longer referenced by any live code, and reclaims their memory automatically. Modern JVMs use generational garbage collection — splitting the heap into Young, Old, and Metaspace regions — because most objects die young (a temporary String, a loop variable), and collecting only the young generation is fast. Real-world impact: A Java server can run for months without a memory leak. This is one of the core reasons enterprises trust Java for long-running systems.

Putting it all together, here's what happens from source code to running program: 1. You write HelloWorld.java 2. javac compiles it to HelloWorld.class (bytecode) 3. You run java HelloWorld 4. The Class Loader loads HelloWorld.class into the JVM 5. The Bytecode Verifier checks it's safe to run 6. The Interpreter begins executing bytecode 7. The JIT Compiler identifies hot methods and compiles them to native code 8. The Garbage Collector runs in the background, reclaiming unused memory 9. Your program runs — identically — on any OS with a JVM installed This layered architecture is why Java has remained the backbone of enterprise software for 30 years. It's not just a language — it's a carefully engineered runtime platform.