Free lesson · Java Basic To Advance

JDK JRE JVM

Easy8 min readjava

Three Things People Confuse

"What's the difference between JDK, JRE, and JVM?" is one of the most-asked Java interview questions. It's so common because it tests whether a candidate actually understands Java's structure or just memorized a textbook definition.

The short answer:

JVM (Java Virtual Machine) — the runtime that executes Java bytecode
JRE (Java Runtime Environment) — the JVM plus the standard libraries needed to run Java programs
JDK (Java Development Kit) — the JRE plus development tools needed to write and compile Java programs

The long answer requires understanding what each actually contains, what each is used for, and how they relate to each other. This Topic walks through that. Nikhil joins for the JVM internals section since runtime model material is his domain on this course.

Interactive animation: Not three options but three rings - the JVM runs bytecode, the JRE adds libraries, the JDK adds tools.

The JVM: What Actually Runs Java

The Java Virtual Machine is a software-implemented "virtual machine" — meaning it pretends to be a CPU, but it's just a program running on your real CPU. It has its own instruction set (Java bytecode), its own execution model, and its own memory layout.

When you run a Java program, the JVM:

Loads your .class files (or JAR files containing them)
Verifies the bytecode is well-formed and safe
Links classes together — resolves references between them
Initializes the classes — runs static initializers
Executes the bytecode through interpretation and JIT compilation
Manages memory through garbage collection
Provides runtime services — threading, reflection, dynamic linking
Exits when main() returns or System.exit() is called

The JVM is specified by the JVM Specification, a formal document describing exactly how a JVM should behave. Multiple vendors implement this specification:

HotSpot — Oracle's reference implementation, used by most JDK distributions
OpenJ9 — Eclipse Foundation's JVM, originally from IBM
GraalVM — Oracle's advanced JVM with polyglot support and ahead-of-time compilation
Azul Zing/Prime — Azul's commercial JVM with low-latency GC
Amazon Corretto's JVM — Amazon's modified HotSpot for AWS workloads

All of these implement the same JVM Specification. A .class file produced by any compiler runs on any of them. The differences are in performance characteristics, GC algorithms, monitoring tools, and licensing.

graph TD
    A[JVM Specification] --> B[HotSpot<br/>Oracle/OpenJDK]
    A --> C[OpenJ9<br/>Eclipse Foundation]
    A --> D[GraalVM<br/>Oracle]
    A --> E[Azul Zing<br/>Commercial]

    F[Any .class file] --> B
    F --> C
    F --> D
    F --> E

    style A fill:#7c3aed,color:#fff
    style B fill:#10b981,color:#fff
    style C fill:#3b82f6,color:#fff
    style D fill:#f59e0b,color:#fff
    style E fill:#ec4899,color:#fff

This diagram shows the relationship between the JVM Specification and JVM implementations. The specification is a formal document maintained by the OpenJDK project. Multiple vendors implement it: HotSpot from Oracle and OpenJDK is the most common, OpenJ9 from Eclipse Foundation is an alternative, GraalVM from Oracle adds polyglot support and ahead-of-time compilation, and Azul Zing is a commercial low-latency option. Any .class file produced by any compiler runs on any of these JVMs because they all conform to the same specification.

What's Inside the JVM (Nikhil's Domain)

Nikhil here. The JVM's internal architecture has several distinct components, each with a specific job. Understanding them is essential for senior interviews on JVM topics.

Class Loader Subsystem. Reads .class files from disk and loads them into the JVM. Multiple class loaders form a hierarchy — the bootstrap class loader loads core Java classes, the platform class loader loads platform extensions, the application class loader loads your application's classes. Custom class loaders enable dynamic loading, hot-reloading, and modular systems.

Runtime Data Areas. The JVM's memory regions:

Method Area (Metaspace in modern JVMs) — stores class metadata, method bytecode, runtime constant pool
Heap — where objects live, divided into generations (young, old) for GC efficiency
Stack — one per thread, stores method call frames with local variables and operand stacks
PC Register — one per thread, tracks current bytecode instruction
Native Method Stack — for JNI (Java Native Interface) calls into C/C++ code

Execution Engine. The code that actually runs bytecode:

Interpreter — executes bytecode one instruction at a time. Slow but works for any code.
JIT Compiler — identifies hot code paths and compiles them to optimized native code. Multiple JITs exist (C1, C2, Graal) at different optimization levels.
Garbage Collector — reclaims memory from unreachable objects. Several algorithms available (G1, ZGC, Shenandoah, Serial, Parallel).

graph TD
    A[JVM] --> B[Class Loader Subsystem]
    A --> C[Runtime Data Areas]
    A --> D[Execution Engine]
    A --> E[Native Method Interface JNI]

    C --> F[Method Area/Metaspace]
    C --> G[Heap]
    C --> H[Stack per thread]
    C --> I[PC Register per thread]

    D --> J[Interpreter]
    D --> K[JIT Compiler C1/C2/Graal]
    D --> L[Garbage Collector]

    style A fill:#7c3aed,color:#fff
    style B fill:#3b82f6,color:#fff
    style C fill:#10b981,color:#fff
    style D fill:#f59e0b,color:#fff
    style E fill:#ec4899,color:#fff

This diagram shows the internal architecture of the JVM. At the top level, the JVM has four main subsystems. The Class Loader Subsystem loads .class files into memory. The Runtime Data Areas hold memory regions: the Method Area or Metaspace for class metadata, the Heap for object storage, a Stack per thread for method call frames, and a PC Register per thread tracking the current instruction. The Execution Engine has three parts: an Interpreter that runs bytecode instruction-by-instruction, JIT Compilers that produce optimized native code for hot paths, and a Garbage Collector that reclaims unreachable memory. The Native Method Interface allows Java code to call into native C or C++ libraries.

Module 19 covers the Java Memory Model and GC algorithms in depth. For now, the key concept: the JVM is a sophisticated runtime, not a simple interpreter. Its complexity is what makes Java performance competitive with native languages.

Interactive animation: Why Java gets faster the longer it runs - the interpreter starts at once, then the JIT compilers take the hot code.

The JRE: JVM Plus Libraries

The Java Runtime Environment is the JVM plus the Java standard library — everything you need to run Java programs but not write them.

Specifically, the JRE includes:

The JVM (HotSpot or another implementation)
The Java standard library (java.lang, java.util, java.io, java.net, all the rest)
Supporting files: configuration, time zone data, fonts, security policies
The java launcher command

What's missing from a JRE (and present in the JDK):

The javac compiler
Development tools (jar, javadoc, jdeps, jlink, jshell)
The java debugger (jdb)
Bytecode tools (javap)
Header file generation for JNI (javah, integrated into javac in modern Java)

A JRE is what you'd ship to end users running a Java application. They don't need to compile anything — they just need to run the bundled JARs and class files.

A note on Java 9+ changes: Starting with Java 9, the separate "JRE" distribution was phased out. Modern JDK distributions ship as a single package. If you want a "JRE-only" distribution for runtime use, you create one with jlink — a tool that builds a custom runtime image containing just the modules your application needs. This produces smaller, more focused runtimes than the old monolithic JRE.

So in 2026, "JRE" is more of a conceptual category than a separate download. The capability still exists (a runtime that can execute Java but not compile it), it's just packaged differently.

The JDK: Everything You Need to Develop

The Java Development Kit is the JRE plus development tools. When you install Java for development (as we did in Topic 1.1), you get a JDK.

graph TD
    A[JDK] --> B[JRE]
    A --> C[Development Tools]

    B --> D[JVM]
    B --> E[Standard Library]

    C --> F[javac compiler]
    C --> G[javadoc]
    C --> H[jar packager]
    C --> I[jshell REPL]
    C --> J[jdb debugger]
    C --> K[jlink, jdeps, jmod]

    style A fill:#7c3aed,color:#fff
    style B fill:#10b981,color:#fff
    style C fill:#3b82f6,color:#fff
    style D fill:#f59e0b,color:#fff
    style E fill:#f59e0b,color:#fff

This diagram shows the relationship between the JDK, JRE, and JVM. The JDK is the outermost package — it contains the JRE plus development tools. The JRE contains the JVM and the standard library. The JVM is the smallest unit — just the runtime engine. Development tools include javac for compilation, javadoc for documentation generation, jar for packaging, jshell for the REPL, jdb for debugging, and jlink, jdeps, and jmod for module operations. As a developer, you install the JDK and get everything below it.

The JDK is what developers install. It contains the JRE (so you can run code) plus the tools to write, compile, package, debug, and document Java applications.

When you run java MyClass on your development machine, you're using:

The java launcher (from the JDK's bin/ directory)
Which starts the JVM (also from the JDK)
Which loads MyClass.class (which you compiled with javac)
Which uses standard library classes from the JDK

The JDK is self-contained — once installed, you have everything you need.

Interactive animation: One install, every ring - javac compiles MyClass.java, then java starts the JVM, which loads MyClass.class.

The Interview Question in Practice

When an interviewer asks "what's the difference between JDK, JRE, and JVM?", the senior-candidate answer covers:

The hierarchy. JDK contains JRE which contains JVM. Each is a subset of the one above.
What each is for. JVM runs bytecode. JRE adds the standard library so you can run Java applications. JDK adds development tools so you can write and compile Java.
Which you install. Developers install the JDK. End users running Java applications historically installed the JRE, though modern Java applications are increasingly distributed with their own runtime via jlink.
The modern caveat. Since Java 9, the JRE is no longer distributed separately — you build a custom runtime with jlink if you need one. The conceptual distinction remains but the packaging changed.

A junior-candidate answer stops at the hierarchy. A senior answer addresses the practical implications and the Java 9 packaging change.

Common Pitfalls

Warning: Saying "JDK is for development and JRE is for production." This was true historically but is misleading now. Modern production applications often ship with their own runtime built via jlink — they don't rely on a separate JRE being installed. The JDK/JRE distinction is more architectural than deployment-related today.

Confusing the JVM with the JIT compiler. The JIT is a component of the JVM, not the same thing. The JVM also includes the interpreter, garbage collector, class loaders, and more.

Thinking there's only one JVM. HotSpot is the most common, but OpenJ9, GraalVM, and others exist. They all implement the same JVM specification. Senior interviews sometimes probe whether candidates know this.

Conflating Java the language with Java the platform. "I write Java" usually means using the language; "I deploy on the JVM" describes the runtime; "the JDK has these tools" describes the development kit. Precise vocabulary signals depth.

Why This Matters in Interviews

Interview: The JDK/JRE/JVM question is asked in roughly 70% of Java-focused phone screens. The expected senior answer covers the hierarchy, what each contains, what each is used for, and ideally a mention of the Java 9+ packaging changes.

Follow-up questions often go deeper into JVM internals: "What are the runtime data areas?" "Explain class loading." "What does the JIT compiler do?" Knowing the JVM architecture diagram above prepares you for these.

Topic 26.12 has the full senior-candidate answer.

Try It

Exercise: Explore your JDK installation:

Run which java (Unix) or where java (Windows) to find the java launcher

The parent directory is your JDK root. Look inside the bin/ directory — list every file

For each tool, run <tool> --help and read the first few lines to understand what it does

Run java -XX:+PrintFlagsFinal -version | head -50 to see the JVM's runtime configuration flags

Knowing what's actually in your JDK installation pays off when you encounter performance issues or need to use a specific tool. Most developers have used java and javac thousands of times without ever looking at jdeps, jlink, or jcmd — all of which are useful.

Back to Java Basic To Advance