The Java Virtual Machine

Traditional Compilation

In a traditional compiled language like C, the pipeline is:

Source code  →  Compiler  →  Platform-specific machine code  →  CPU executes directly
  (.c)           (gcc)             (.exe / ELF / Mach-O)

The compiler translates the source directly into the native instruction set of the target CPU (x86-64, ARM, etc.). The resulting executable runs at full native speed, but it only works on the platform it was compiled for. To support Windows, macOS, and Linux, you must compile three separate binaries — and that is before considering different CPU architectures.

The Java Model

Java uses a two-stage compilation model:

Source code  →  javac  →  Bytecode  →  JVM interprets/JIT-compiles  →  Native machine code
  (.java)                 (.class)         (at runtime)

Stage 1: Source to Bytecode

The Java compiler (javac) translates .java source files into .class files containing bytecode. Bytecode is a platform-independent intermediate representation — a kind of portable assembly language. It is not tied to any particular CPU architecture. The bytecode instructions operate on an abstract stack machine rather than physical registers.

Stage 2: Bytecode to Native Code

At runtime, the Java Virtual Machine (JVM) loads the bytecode and executes it. Two execution strategies are used, often in combination:

• Interpretation: the JVM reads each bytecode instruction and carries out the corresponding operation. Slow but starts immediately.
• Just-In-Time (JIT) compilation: the JVM identifies frequently executed code (hot spots) and compiles those bytecode sequences into native machine code on the fly. Subsequent executions of that code run at near-native speed.

Modern JVMs (like HotSpot) use tiered compilation: start with interpretation, then apply increasingly aggressive optimisations as code proves itself hot.

”Write Once, Run Anywhere”

Because bytecode is platform-independent, the same .class file can run on any machine that has a JVM installed — whether it is a Windows x86 machine, a macOS ARM laptop, or a Linux server. The JVM abstracts away the underlying operating system and hardware.

This was a revolutionary idea when Java was released in 1995. At the time, cross-platform development usually meant maintaining separate codebases or wrestling with #ifdef preprocessor directives.

Pros and Cons

Advantages

• Portability: compile once, deploy anywhere with a JVM
• Memory safety: no raw pointers, no manual memory management, arrays are bounds-checked — entire classes of C/C++ bugs (buffer overflows, use-after-free, double-free) are eliminated
• Automatic garbage collection: the JVM reclaims memory from objects that are no longer reachable, removing the burden of manual free() and eliminating memory leaks from forgotten deallocations
• Rich standard library: the JDK provides data structures, networking, I/O, concurrency, and much more out of the box

Disadvantages

• Startup overhead: the JVM must initialise itself, load classes, and warm up the JIT compiler before reaching peak performance — a native binary starts instantly
• Runtime dependency: the target machine must have a JVM installed (though jlink and jpackage can bundle a minimal runtime)
• Execution overhead: interpreted or not-yet-JITted code runs slower than native code, though heavily optimised JIT code can sometimes outperform ahead-of-time compiled code because JIT optimisation has runtime information available

The Broader JVM Ecosystem

The two-stage model has an important consequence: any language that can compile to JVM bytecode can run on the JVM and interoperate with Java code. The JVM has become a polyglot platform:

• Kotlin: a modern, concise alternative to Java (now Google’s preferred language for Android)
• Scala: fuses object-oriented and functional programming
• Clojure: a dynamic, functional Lisp dialect
• Groovy: a dynamic scripting language with Java-friendly syntax

All of these languages share the JVM’s garbage collector, threading model, and standard library access. A Kotlin class can extend a Java class; a Scala function can call a Java method. The JVM is the common substrate that makes this possible.