JDK vs JRE vs JVM: What's the Difference?

Ask ten Java freshers what the JVM does and you will get ten vague answers about "running Java". Yet "explain JDK vs JRE vs JVM" is often the second or third question in a Java interview, right after "tell me about yourself". The difference is genuinely simple once you see the three as layers of a stack, each wrapping the one below it.

The 30-second answer

The containment relationship is the key mental model:

JDK  ⊃  JRE  ⊃  JVM
(develop)  (run)   (execute)

You write code with the JDK, ship it to an environment that has a JRE, and the JVM inside that JRE does the actual execution.

What is the JVM?

The Java Virtual Machine is a specification — and its implementations — for an abstract computer that executes bytecode, the intermediate format produced when you compile .java files. The JVM is responsible for:

• Loading classes from .class files and JARs (the class loader subsystem).
• Verifying bytecode so corrupt or malicious class files cannot crash the process.
• Executing instructions, first by interpreting them, then by JIT-compiling frequently used methods into native machine code.
• Managing memory — allocating objects on the heap and reclaiming dead ones through garbage collection.

Here is the point interviewers probe: the JVM is platform specific. A Windows JVM and a Linux JVM are different programs. What is platform independent is the bytecode they both accept. That separation is exactly how Java achieves "write once, run anywhere".

Interview note: If asked "Is the JVM platform independent?", the precise answer is no — bytecode is platform independent, the JVM is platform dependent. Candidates who state this distinction cleanly stand out immediately.

If you want to go one level deeper — class loader hierarchy, runtime data areas, execution engine — that is covered in JVM architecture.

What is the JRE?

The Java Runtime Environment is the JVM plus everything a program needs at runtime:

• The core class libraries: java.lang, java.util, java.io, collections, networking, and so on. When your code calls System.out.println, the implementation lives in these libraries.
• Supporting files such as property settings and integration components.

Think of the JRE as "the JVM with batteries included". The JVM alone can execute bytecode, but your bytecode constantly calls built-in classes like String and ArrayList — the JRE supplies them.

One modern wrinkle worth knowing: since Java 11 there is no separate JRE download from Oracle or OpenJDK. The JDK is the standard install, and applications that need a lean runtime create their own with the jlink tool. When an interviewer asks about the JRE, they are testing the concept, not the download page.

What is the JDK?

The Java Development Kit is the full toolbox. It contains the JRE (and therefore the JVM) plus the tools you use as a developer:

If you plan to write even one line of Java, you install the JDK. There is no scenario where a developer installs "just the JRE".

Pro tip: After installing, verify both halves of the toolchain: java -version proves the runtime works, and javac -version proves the compiler is on your PATH. When beginners see "javac is not recognized", the JDK's bin folder is missing from the PATH environment variable — fixing that solves 90% of setup complaints.

How the three work together: compile and run

Watch the full journey of one program. Save this as LifeCycle.java:

public class LifeCycle {
    public static void main(String[] args) {
        String stage = "bytecode -> JVM -> output";
        System.out.println("This text traveled: " + stage);
    }
}

Step 1 — the JDK compiles it:

javac LifeCycle.java     // produces LifeCycle.class (bytecode)

Step 2 — the JVM (launched via the java command, using JRE libraries) runs it:

java LifeCycle           // prints: This text traveled: bytecode -> JVM -> output

During step 2, the class loader reads LifeCycle.class, the verifier checks it, the interpreter starts executing main, and the String and System classes are pulled from the runtime libraries. If main ran millions of times, the JIT compiler would translate it to native code for speed.

You can even peek at the bytecode yourself with the JDK's disassembler: javap -c LifeCycle prints the JVM instructions (ldc, invokevirtual and friends) generated from your five lines of source. Nothing demystifies "what is bytecode" faster than reading some.

Seeing the JVM from inside your program

The JVM is not an abstract idea — your code can query it at runtime. This example asks the running JVM about itself:

public class JvmInfo {
    public static void main(String[] args) {
        Runtime rt = Runtime.getRuntime();
        long maxHeapMb = rt.maxMemory() / (1024 * 1024);

        System.out.println("Java version : " + System.getProperty("java.version"));
        System.out.println("JVM name     : " + System.getProperty("java.vm.name"));
        System.out.println("OS           : " + System.getProperty("os.name"));
        System.out.println("Max heap     : " + maxHeapMb + " MB");
        System.out.println("CPU cores    : " + rt.availableProcessors());
    }
}

Run it and notice two things. The java.vm.name property names the actual JVM implementation (typically HotSpot). And maxMemory() reveals the heap ceiling the JVM chose for your machine — memory it manages for you automatically, a topic explored fully in Java memory management.

Common mix-ups to avoid

Common mistake: A common mistake beginners make is saying "the JDK runs my program". The JDK is a development kit — the java launcher inside it starts a JVM, and the JVM runs the program. Keep the verbs straight: JDK builds, JVM executes, JRE supplies the runtime pieces.

A few more distinctions that trip up freshers:

• JVM ≠ compiler. The compiler (javac) works before runtime and lives in the JDK. The JVM's JIT compiler is a different thing — it optimizes bytecode into machine code while the program runs.
• Bytecode ≠ machine code. Bytecode is for the JVM; machine code is for your CPU. The JVM bridges the two.
• Garbage collection belongs to the JVM, not to the language syntax. You never call it directly; the JVM decides when to reclaim memory. The mechanics are covered in Java garbage collection.

How to answer this in an interview

A crisp 40-second answer that consistently lands well:

"The JVM is the virtual machine that executes Java bytecode — it handles class loading, execution and garbage collection, and it is platform specific while bytecode is platform independent. The JRE is the JVM plus the core libraries, so it is what you need to run Java applications. The JDK is the JRE plus development tools like javac and jshell, so it is what developers install. JDK contains JRE, JRE contains JVM."

Then stop. Do not ramble into JIT internals unless asked — but be ready for the follow-ups: "Is JVM platform independent?" (no, bytecode is), "What does JIT do?" (compiles hot bytecode to native code at runtime), and "Why can't we just run .java files directly?" (since Java 11 you actually can for single files with java LifeCycle.java, which compiles in memory first — mentioning this earns bonus points).

Where to go next

Now that you know what executes your code, the natural next step is learning what your code is made of: Java data types covers the eight primitives and reference types that every program is built from. And when you are ready for the deep end, JVM architecture opens up the machinery you just met from the outside.