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 tools — javac (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.