Diff — Java Virtual Machine

{{infobox

| title = Java Virtual Machine

| name = JVM

| developer = Sun Microsystems (1995) → Oracle (2010); OpenJDK is the reference implementation

| first_release = January 23, 1996 (Java 1.0)

| written_in = C++ (HotSpot)

| license = GPLv2 + Classpath exception (OpenJDK)

| executes = JVM bytecode (.class files)

| website = openjdk.org

}}

# Java Virtual Machine

The **Java Virtual Machine** is the most successful runtime platform ever built — a specification for a portable abstract computer that has been executing the same `.class` bytecode format unchanged since 1995. When James Gosling's team at Sun Microsystems shipped Java 1.0 with the slogan **"Write Once, Run Anywhere"**, the JVM was the machine that made the slogan technically true.

The JVM's genius was separating the *language* from the *platform*. `javac` — the Java compiler — translates Java source into **JVM bytecode**, a compact stack-machine instruction set stored in `.class` files. The JVM then executes that bytecode. Java the language and the JVM the platform are separate contracts: the language is what programmers write, the bytecode is what the machine runs, and any language that can emit valid bytecode — Java, Kotlin, Scala, Groovy, Clojure — can run on the same runtime.

# javac, bytecode, and the class file

`javac` is deliberately simple: it parses Java source, type-checks it, and emits `.class` files containing bytecode. It performs almost no optimization — nearly all the cleverness is deferred to the JVM at runtime. A Java "executable" is not machine code; it is a portable intermediate form that requires a JVM to run.

A `.class` file is a binary structure containing a constant pool, the class's methods, and a stream of bytecode instructions like `iload`, `invokevirtual`, `getfield`, `aload`, `areturn`. The JVM loads classes on demand, verifies their bytecode for type safety (the *bytecode verifier* — a security feature, not just a correctness check), links them, and executes.

# HotSpot — the JIT that made Java fast

Java was slow for its first five years because early JVMs were pure interpreters — every bytecode instruction was dispatched and executed one at a time. **HotSpot**, which Sun acquired in 1997 with Animorphic Systems and shipped in Java 1.3 (2000), changed everything.

HotSpot is a *just-in-time* compiler built into the JVM. While a program runs, HotSpot profiles which methods are hot — executed thousands of times — and selectively compiles them to optimized machine code, inlining methods, eliminating bounds checks, removing synchronization where escape analysis proves it unnecessary, and even making *speculative* optimizations based on observed types that can be rolled back (deoptimization) if the assumptions change.

The result is that a long-running Java program's hot loops often run at speeds comparable to statically compiled C++ — the JVM has information (which classes are actually loaded, which branches are actually taken, which objects actually escape) that no ahead-of-time compiler can see. Modern HotSpot uses **tiered compilation**: the fast C1 compiler compiles quickly for warm code, the aggressive C2 compiler compiles the hottest paths, and the interpreter handles the cold rest.

# The JVM as a language platform

Sun deliberately kept the bytecode specification open, and the industry responded by treating the JVM as the industry's shared runtime. Today the JVM hosts dozens of languages:

| Language | Compiler | Target |

|---|---|---|

| Java | `javac` | `.class` bytecode |

| Kotlin | `kotlinc` | `.class` bytecode (primary target) |

| Scala | `scalac` | `.class` bytecode |

| Groovy | `groovyc` | `.class` bytecode |

| Clojure | Clojure compiler (in Clojure) | bytecode, dynamically emitted |

| JRuby | jruby | bytecode |

| Jython | jython | bytecode |

Kotlin — JetBrains's pragmatic Java replacement and the official Android language — compiles to JVM bytecode and is fully interoperable with Java at the class-file level: Kotlin classes call Java methods and vice versa with zero bridging. The `.class` file became so durable that Java code compiled in 1996 still runs unmodified on a 2025 JVM.

# Garbage collection

The JVM pioneered production garbage collection. Its collectors are a field of study in themselves: the **G1** region-based collector (default since Java 9), the ultra-low-latency **ZGC** and **Shenandoah** (pause times measured in microseconds even on terabyte heaps), and the classic generational collectors. GC tuning — heap sizing, young/old ratios, pause targets — is a real engineering discipline because the JVM's garbage collector is visible in the performance profile of every large Java service on Earth.

# Android — the parallel universe

Android does not run JVM bytecode at all — it runs **Dalvik/ART bytecode** (`.dex` files), a register-based VM format designed for low-memory mobile devices. Java source is compiled by `javac` (or `kotlinc`) to `.class`, then Android's `d8` tool converts `.class` to `.dex`. Android Runtime (ART) then ahead-of-time compiles `.dex` to native ARM code at install time — a completely different model from HotSpot's JIT. Google's adoption of Java's language but not its bytecode became the subject of *Oracle v. Google* (2010–2021), the largest copyright lawsuit in software history, which the Supreme Court decided in Google's favor (fair use of the API declarations).

# GraalVM and native images

**GraalVM** is the JVM's radical fork: a high-performance polyglot VM that can ahead-of-time compile JVM bytecode to a *native executable* with no JVM required (`native-image`). A GraalVM-compiled Java program starts in milliseconds with a tiny memory footprint — Java's answer to Go and Rust's static binaries. GraalVM also runs JavaScript, Python, Ruby, and other languages through its Truffle framework, making it less a Java VM than a universal runtime that happens to speak bytecode.

# See also

- [[Compilers]] — the toolchain families compared

- [[Kotlin]] · [[Scala]] · [[Groovy]] — JVM languages

- [[Android]] · [[Google]] — the JVM's largest battleground

- [[GCC]] · [[LLVM]] — the native-toolchain counterparts

- [[AdaLogic BASIC]] — ALB's .NET backend emits C# for the CLR, the JVM's .NET twin

- [[History of Programming]]

# References

2. Goetz, Brian. *Java Concurrency in Practice* (2006) — the JVM memory model.

[[Category:Programming]]

[[Category:Technology]]

[[Category:Languages]]