Java Virtual Machine

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:

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

1. Lindholm, Yellin, Bracha, Buckley, Smith. The Java Virtual Machine Specification, Java SE 21 Edition (Oracle, 2023) — the bytecode contract.
2. Goetz, Brian. Java Concurrency in Practice (2006) — the JVM memory model.
3. Oracle v. Google, 593 U.S. ___ (2021) — the API fair-use decision.
4. OpenJDK source — openjdk.org — HotSpot, javac, and the collectors in C++.
5. GraalVM documentation — graalvm.org.
6. "The Java Language Specification" (JLS) — javac's contract.