JVM vs JRE vs JDK — Disambiguating the Java Runtime Stack

JVM vs JRE vs JDK — the three layers

JVM (Java Virtual Machine)

• The runtime engine that executes bytecode
• A specification, with multiple implementations
• HotSpot, OpenJ9, GraalVM, Azul Zing

JRE (Java Runtime Environment)

• JVM + standard class libraries (java., javax.)
• Enough to run Java apps
• NOT enough to compile
• Discontinued as separate download in Java 11

JDK (Java Development Kit)

• JRE + development tools
• javac, jar, javadoc, jdb, jshell
• Diagnostic tools: jstack, jmap, jstat, jcmd
• Build tools: jlink, jpackage, jdeps
• Needed to develop and ideal for production

Hierarchy: JDK ⊃ JRE ⊃ JVM

Java 9 changes (Project Jigsaw / JPMS)

• Modules introduced
• Standard library split into modules (java.base, java.sql, java.xml)
• jlink tool builds custom minimal runtimes
• Container images can be 50MB instead of 200MB+

Java 11 change

• Separate JRE distribution removed
• jlink supersedes 'here's the runtime'
• Most users either needed JDK (devs) or even smaller runtimes

OpenJDK vs Oracle JDK

• Same source code (since Java 11)
• Different branding, license, support model
• Oracle JDK: commercial license for production after Java 11
• OpenJDK builds (free):

  • Eclipse Temurin (most popular)
  • Amazon Corretto (LTS, AWS)
  • Azul Zulu
  • Microsoft OpenJDK
  • Red Hat OpenJDK
  • BellSoft Liberica
  • GraalVM

LTS versions

• Java 8 (2014), 11 (2018), 17 (2021), 21 (2023)
• LTS = long-term support (~5+ years)
• Production should use LTS

JVM implementations

HotSpot (default)

• Tiered JIT (C1 + C2)
• Used by 95%+ of Java workloads

OpenJ9 (Eclipse, formerly IBM)

• Lower memory footprint
• Faster startup
• Good for containers

GraalVM

• Polyglot JVM (Java + Python + JS + Ruby + R)
• Graal JIT (written in Java)
• native-image: AOT compile to native binary
• Sub-second startup; ideal for serverless / CLI
• Restrictions: reflection / dynamic class loading need configuration

Azul Zing / Prime

• C4 (Continuously Concurrent Compacting Collector)
• Pauseless GC even at multi-TB heaps
• Trading, telecom, low-latency systems

Diagnostic tools (in JDK)

• jstack — thread dump
• jmap — heap dump
• jstat — JVM statistics over time
• jcmd — send commands to running JVM
• jfr — Java Flight Recorder (free since Java 11)

For containers

Use jlink for minimal runtimes:

jdeps --print-module-deps myapp.jar
jlink --add-modules <list> --output runtime

Multi-stage Docker build: build with full JDK, copy jlink output to slim runtime image.

Alternative: GraalVM native-image → statically linked binary, ~30MB, sub-second startup.

Common bugs / misconceptions

1. 1
   Thinking JRE includes the compiler (it doesn't)
2. 2
   Confusing JVM (spec) with HotSpot (impl)
3. 3
   Not knowing JRE was discontinued in Java 11
4. 4
   Using full JDK image in containers (wasteful)
5. 5
   Confusing Oracle JDK vs OpenJDK (same code)

For interviews

• Lead with the three-tier hierarchy
• Mention multiple JVM implementations
• Discuss Java 9 jlink and Java 11 JRE removal
• Address Oracle JDK vs OpenJDK landscape
• Mention GraalVM native-image for serverless / fast startup

Recommendation: Remember the three-tier hierarchy: JVM (specification + runtime engine that executes bytecode), JRE (JVM + standard libraries to run apps), JDK (JRE + dev tools to develop apps). The relationship is JDK ⊃ JRE ⊃ JVM. Since Java 9 introduced the module system (JPMS), you can build a custom minimal runtime with `jlink` containing only the modules your app needs — this is the modern replacement for 'just JRE' and is essential for slim container images (50MB vs 200MB+). Java 11 removed the separate JRE distribution entirely — install the JDK or build a custom runtime with jlink. Multiple JVM implementations exist beyond HotSpot: OpenJ9 (low memory, fast startup, good for containers), GraalVM (polyglot, AOT-compiles to native binaries via native-image for sub-second serverless startup), Azul Zing (pauseless C4 GC for low-latency trading). Multiple OpenJDK distributions are free and production-ready: Eclipse Temurin (most popular), Amazon Corretto (AWS-supported LTS), Azul Zulu, Microsoft OpenJDK, Red Hat OpenJDK, BellSoft Liberica. For production, deploy on a JDK (you'll need diagnostic tools like jstack, jmap, jcmd, jfr); for containers, build a jlink minimal runtime in a multi-stage Docker build; for serverless / CLI tools, consider GraalVM `native-image` for sub-second startup. Stick to LTS versions (Java 8, 11, 17, 21) in production. The mental model: JVM = engine, JRE = engine + libraries, JDK = JRE + dev tools — with jlink replacing the standalone JRE in the modular Java era.