Skip to content

JVM vs JRE vs JDK: What They Mean

If you have ever googled "jvm full form" or wondered what the difference between JDK, JRE and JVM is — this page is for you. Five minutes from now the terms will never confuse you again.

JVM — Java Virtual Machine

JVM (Java Virtual Machine) is the program that actually runs your Java code. Instead of executing your .java source directly, the Java toolchain works like this:

  1. javac (in the JDK) compiles your source into bytecode (.class files).
  2. The JVM loads the bytecode, verifies it, and executes it — translating it to native machine instructions (via interpretation and JIT compilation).
  3. While running, the JVM manages memory for your application: allocating objects on the heap and reclaiming dead objects with garbage collection (GC).

Because each operating system has its own JVM implementation (Windows, Linux, macOS…), the same bytecode runs everywhere — the famous "write once, run anywhere".

JRE — Java Runtime Environment

The JRE is the JVM plus the core class libraries your application needs at runtime (java.lang, java.util, the networking and I/O stacks…). If you only want to run Java applications, the JRE is enough.

Since Java 11

Oracle stopped shipping a standalone JRE download — modern JDKs (11, 17, 21, 25) can run applications directly with java, and you produce trimmed runtimes with jlink.

JDK — Java Development Kit

The JDK is the full toolbox: JRE + development toolsjavac (compiler), jdb (debugger), jmap (heap dumps), jstack (thread dumps), jcmd, and more. If you write Java code, you need the JDK.

The relationship in one picture

┌─────────────────────────────┐
│ JDK                         │
│  ┌───────────────────────┐  │
│  │ JRE                   │  │
│  │  ┌─────────────────┐  │  │
│  │  │ JVM             │  │  │
│  │  │  + class loader │  │  │
│  │  │  + bytecode     │  │  │
│  │  │    interpreter  │  │  │
│  │  │  + JIT compiler │  │  │
│  │  │  + GC engine    │  │  │
│  │  └─────────────────┘  │  │
│  │  + core libraries     │  │
│  └───────────────────────┘  │
│  + javac, jmap, jstack …    │
└─────────────────────────────┘

JDK ⊃ JRE ⊃ JVM. Every JDK can run and compile; a JRE can only run.

Where garbage collection fits

The JVM divides memory into regions — the ones that matter for GC are:

AreaWhat lives thereWho cleans it
Young Gen (Eden + Survivors)newly created objects, most of them short-livedMinor / Young GC — frequent, fast
Old Gen (Tenured)objects that survived several collectionsMajor GC / Full GC — expensive
Metaspaceclass metadataFull GC when full

When the Young Gen fills up, the JVM stops the application threads and collects garbage — that's the GC pause you see in logs. If pauses are frequent or long, your users feel it as latency.

Analyze your JVM's GC behavior

GC logs are the flight recorder of the JVM. Drop one into the GC Log Analyzer to see throughput, pause times, allocation rate and memory-leak signals in seconds.