BeginnerIn-depth3 min readUpdated 2 Oct 2026

What is the difference between JDK, JRE and JVM?

SHORT ANSWER

The JVM runs Java bytecode. The JRE is the JVM plus the standard libraries needed to run a program. The JDK is the JRE plus developer tools such as the javac compiler, so you need the JDK to write and build Java, and only a runtime to run it.

Explain it simply

Think of a cricket match on TV. The JVM is the TV set: it takes a signal and shows the match. The JRE is the TV plus the set-top box and cables, everything a viewer needs to watch at home. The JDK is the whole broadcast studio: cameras, editing desks and the people who produce the match, plus a TV to check how it looks.

A viewer only needs the TV setup. A broadcaster needs the full studio. In the same way, a user only needs a runtime to run a Java program, while a developer needs the JDK to write, compile and test it.

Example

text

Hello.java  --(javac, part of the JDK)-->  Hello.class (bytecode)
Hello.class --(java launcher starts the JVM)-->  program runs

java

public class Hello {
    public static void main(String[] args) {
        System.out.println("Namaste, Java"); // prints: Namaste, Java
    }
}

You run javac Hello.java to create Hello.class, then java Hello to run it. The first step needs the JDK. The second step needs only a JVM with the standard library.

How it works

JVM (Java Virtual Machine): loads .class files, checks the bytecode is safe, and executes it. It interprets bytecode at first, then the JIT (just-in-time) compiler turns frequently used code into fast native machine code. It also manages memory through garbage collection. There is a different JVM for Windows, Linux and macOS, which is why the same bytecode runs everywhere: "write once, run anywhere".
JRE (Java Runtime Environment): the JVM plus the core class libraries such as java.lang, java.util and java.io. Your program cannot even print without these.
JDK (Java Development Kit): the JRE plus tools like javac (compiler), jar (packaging), javadoc, jdb (debugger), jshell and jlink.

So the relationship is nested: JDK contains JRE, and JRE contains JVM.

Real-world use

On your laptop you install a JDK, for example JDK 21, to build a Spring Boot project. On a production server, teams often ship a slimmer runtime image built with jlink or a small Docker base image, because the server only needs to run the app, not compile it.

Common mistakes

Saying the JVM compiles Java source code. javac compiles source to bytecode; the JVM runs bytecode (and its JIT compiles bytecode to machine code).
Saying Java bytecode is platform-dependent. Bytecode is the same everywhere; the JVM is what differs per platform.
Expecting a separate JRE download for modern Java. Since Java 11, Oracle and most vendors ship the JDK, and you build a custom runtime with jlink if you need one.

What to say in the interview

"The JVM is the engine that loads and executes bytecode, handles memory and garbage collection, and uses a JIT compiler for speed. The JRE is the JVM plus the standard libraries, which is what you need to run a Java program. The JDK is the JRE plus development tools like javac, jar and the debugger, which is what you need to build one. So JDK contains JRE, which contains JVM. Java is platform independent because bytecode is the same everywhere, and each operating system has its own JVM."

Follow-up questions

Is the JVM platform independent?
What is the JIT compiler and why does it make Java fast?
What is bytecode?
What does a class loader do?

Go deeper

Read these once the basics above feel easy.

The JVM has a few main parts. The class loader subsystem loads classes in a parent-first order (bootstrap, platform, application loaders). The runtime data areas include the heap (objects), the stack for each thread (method frames and local variables), and the metaspace (class metadata, which replaced PermGen in Java 8). The execution engine has the interpreter, the JIT compiler and the garbage collector. HotSpot, the most common JVM, watches which methods are "hot" and compiles them to native code, which is why a Java service often gets faster after it has been running for a while.

#java #jvm #jdk #jre #fundamentals