JDK, JRE and JVM explained

For this lesson, we'll focus on what each layer contains, what it does when you type java Hello, and how the picture changed after Java 9 and Java 11. It sounds like trivia, and it's usually the first warm-up question in a Java interview. A crisp answer sets the tone, and the JVM is the thing we'll keep coming back to for the rest of this course, so let's get the picture straight now.

01Picture it first: three boxes

Think of a restaurant. The JVM is the stove: it does the actual cooking. The JRE is the stove plus a stocked pantry (the class library), enough to serve meals someone else wrote the recipes for. The JDK is the whole kitchen, including the knives and the recipe-writing desk (javac, javadoc, the profilers) you need to create new dishes.

The three are nested, like boxes inside boxes:

Fig. 1

The JDK contains developer tools and the JRE; the JRE contains the class library and the JVM

If you remember nothing else, remember this: JDK ⊃ JRE ⊃ JVM. Every tool you use to build software lives in the outer ring, and only the inner box ever executes your code.

02Under the hood: who does what when you run a program

Here's the smallest program that touches all three layers:

public class Hello {
    public static void main(String[] args) {
        System.out.println("Hello, Atlas");
    }
}

javac Hello.java      # JDK tool: source -> bytecode (Hello.class, 416 bytes on JDK 21)
java Hello            # launcher starts the JVM, which loads and runs Hello.class
java -version         # ask which VM you are actually running

On my machine, the last command prints OpenJDK 64-Bit Server VM (build 21.0.12, mixed mode, sharing). That one line tells you a lot: the VM is HotSpot's Server VM, "mixed mode" means it both interprets and JIT-compiles, and "sharing" means Class Data Sharing is on, so core classes are mapped from a pre-built archive instead of being parsed again at every start.

Notice three things:

• javac is a JDK tool. It produces bytecode, instructions for an abstract machine, not machine code for your CPU.
• java is a small native launcher. It finds a JVM library (libjvm), creates the VM, and asks it to load Hello.
• System.out.println is not part of the JVM. It's library code in the java.base module, which is the "JRE" part of the picture.

Inside the JVM box there are three moving parts: the class loader subsystem (finds .class bytes), the runtime data areas (heap, one stack per thread, metaspace for class metadata) and the execution engine (interpreter, JIT, garbage collector). We open each of these up in the next lesson.

03Why "write once, run anywhere" works, and where it doesn't

The same Hello.class runs on Linux, macOS and Windows because each platform has its own JVM that understands the same bytecode. The platform-specific work moved out of your code and into the JVM, which is itself a native program compiled separately for each OS and CPU. That's why you download a different JDK for linux-x64, macos-aarch64 and windows-x64, but ship the same JAR to all of them.

It's really "run anywhere there's a compatible JVM". Two limits matter in practice:

• Version. Bytecode carries a class-file version (65 for Java 21). An older JVM refuses newer bytecode with UnsupportedClassVersionError. Compile with javac --release 17 if you must run on Java 17.
• The world outside the JVM. Native libraries loaded through JNI, file path separators, line endings and default charsets (UTF-8 by default only since Java 18) can still differ per platform.

04Real world: where did the JRE go?

Up to Java 8, Oracle shipped two downloads: a JRE for end users and a JDK for developers. The JDK even contained a full copy of the JRE in a jre/ folder, and the whole class library lived in one rt.jar file of about 60 MB.

Java 9 changed the layout. The Java Platform Module System split the library into modules (java.base, java.sql, java.desktop and so on), rt.jar was replaced by a compact lib/modules image, and a new tool, jlink, arrived to assemble custom runtimes. Java 11 finished the job: Oracle stopped shipping a separate JRE, and applets and Java Web Start were removed. The intended model today is "the application ships its own runtime".

Here's how I'd build one by hand:

# Which JDK modules does my app need?
jdeps --print-module-deps --ignore-missing-deps target/app.jar
# -> java.base,java.logging,java.sql

# Build a runtime with only those modules
jlink --add-modules java.base,java.logging,java.sql \
      --strip-debug --no-header-files --no-man-pages \
      --compress=zip-6 --output build/runtime

build/runtime/bin/java -jar target/app.jar

The picture below shows what jlink keeps and what it throws away:

Fig. 2

jlink copies only the modules your application needs from the full JDK into a small custom runtime with its own java launcher

On JDK 21, a java.base-only image measured about 46 MB, and 28 MB with the stripping flags above. There's no javac inside, and that's the point: a production runtime shouldn't carry a compiler.

public class WhereAmI {
    public static void main(String[] args) {
        System.out.println("Java version : " + Runtime.version());
        System.out.println("VM           : " + System.getProperty("java.vm.name"));
        System.out.println("Runtime home : " + System.getProperty("java.home"));
        System.out.println("Modules      : " + ModuleLayer.boot().modules().size());
    }
}

Both runs report the same version and the same OpenJDK 64-Bit Server VM, because jlink copies the real HotSpot VM. Only java.home and the module count differ: 62 boot modules on the full JDK 21, exactly 1 on the trimmed image. Try java WhereAmI.java (source launch) on the trimmed runtime and it fails with Module jdk.compiler not in boot Layer, which is a neat proof that the compiler really is gone.

05Advanced: one spec, many JVMs

Many candidates treat "Java" and "HotSpot" as the same thing. There's a useful distinction between a JVM implementation and a JDK distribution:

• Distributions are builds of OpenJDK with different support policies: Eclipse Temurin, Amazon Corretto, Azul Zulu, Microsoft Build of OpenJDK, Oracle's own builds. Almost all of them run the HotSpot VM, so they behave the same at runtime.
• Implementations are different virtual machines. HotSpot is the reference, with the C1 and C2 JIT compilers and collectors like G1 and ZGC. Eclipse OpenJ9 (from IBM) targets lower memory footprint and faster startup. GraalVM replaces C2 with the Graal compiler written in Java, and its Native Image tool compiles ahead of time into a standalone binary with no JVM at runtime. Azul's Platform Prime ships its own Falcon JIT and pauseless collector.

All of them pass the same compatibility test kit (TCK), so your bytecode means the same thing everywhere. What differs is startup time, peak throughput, memory and tuning flags.

06How to say it in the interview

When I ask this, I'm listening for three things: do you get the nesting right without hesitating, do you know which compiler lives where (javac versus the JIT), and do you know that the separate JRE is gone since Java 11. This is where you can show depth by mentioning jlink and naming a second JVM implementation.

Here's how this might look on the whiteboard: