JDK vs JRE vs JVM: The Difference, Explained Simply

Three abbreviations turn up on the first day of Java and never get properly explained: JDK, JRE, and JVM. They are not three competing things you choose between. They nest inside each other, like a toolbox containing a car containing an engine.

• The JDK is the toolbox. It builds Java programs.

• The JRE is the car. It runs them.

• The JVM is the engine. It executes the instructions.

The JDK contains a JRE. The JRE contains a JVM. That single sentence answers most of the questions people search for, and the rest of this article explains why it is true and what follows from it.

JDK vs JRE vs JVM at a Glance

The last row is the one that trips people up, and it gets its own section below.

What Is the JDK?

The JDK, or Java Development Kit, is what you install to write Java. It is a superset of everything else on this page.

What you get inside it:

• javac, the compiler. It turns human-readable .java source files into .class files containing bytecode.

• java, the launcher. It starts a JVM and runs a compiled class or a .jar file.

• jdb, the debugger, for stepping through running code.

• javadoc, which generates HTML API documentation from the comments in your source.

• jar, which packages compiled classes into a single distributable archive.

• The full standard class library, everything under java.* and javax.*.

• A JVM, so you can run what you just built.

You need the JDK if you write Java, compile Java, or run anything built with a tool that compiles Java, which includes Maven, Gradle, and every Spring Boot project.

See the JDK Working

Create a file called Hello.java:

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

Compile it, then run it:

javac Hello.java
java Hello

The first command is the JDK doing its job: it produces Hello.class, which is bytecode, not machine code. The second command is the JRE and JVM doing theirs: java starts a JVM, the JVM loads Hello.class, and executes it.

You can prove the intermediate step exists:

javap -c Hello.class

That prints the bytecode instructions inside the class file. Those instructions are what the JVM reads, and they are identical on Windows, macOS, and Linux.

What Is the JRE?

The JRE, or Java Runtime Environment, is everything needed to run a compiled Java program and nothing needed to build one.

Inside it:

• A JVM.

• The standard class libraries the running program calls into.

• Supporting files, such as configuration and property files.

Not inside it:

• No compiler. You cannot turn .java into .class with a JRE.

• No debugger, no javadoc, no jar.

The JRE existed as a separate download because of a distinction that mattered in the desktop era: end users ran Java applications without ever compiling anything, so shipping them a compiler was pointless.

The Part Most Articles Get Wrong

Oracle stopped shipping a standalone JRE after Java 8. From Java 11 onward there is no separate JRE download from Oracle, and most OpenJDK distributions do not offer one either. Modern Java applications are expected to bundle their own runtime, assembled with the jlink tool, which builds a minimal runtime image containing only the modules the application actually uses.

Practically, this means the JDK-versus-JRE decision has mostly disappeared. If you are choosing something to install in 2026, install a JDK. The concepts still matter, because the layering explains how Java works and the terms are everywhere in documentation, error messages, and interview questions.

What Is the JVM?

The JVM, or Java Virtual Machine, is the piece that actually runs your code. It is a specification with multiple implementations, the most common being HotSpot, which ships with most JDK distributions.

What it does while your program runs:

• Loads classes. It finds .class files on the classpath and loads them on demand, not all at once.

• Verifies bytecode. Before executing anything it checks the bytecode is well formed and cannot violate memory safety. This is why a corrupted class file produces a VerifyError rather than a crash.

• Executes bytecode. It starts by interpreting, and its just-in-time compiler then compiles the hot paths to native machine code while the program runs. This is why a long-running Java service gets faster in its first minutes.

• Manages memory. It allocates objects on the heap and reclaims them with a garbage collector, so your code never frees memory by hand.

• Enforces runtime constraints, such as security policies and stack limits.

You do not install a JVM by itself. It arrives inside a JDK or a runtime image.

Is the JVM Platform-Independent or Platform-Dependent?

This is the most misread question in Java, and the answer is short:

Java bytecode is platform-independent. The JVM is platform-dependent.

The reason is the whole design. javac compiles your source to bytecode, which targets the JVM specification rather than any real processor. That bytecode file is byte-for-byte the same on every operating system. To actually execute it, something has to translate those instructions into real instructions for a real chip, and that something is the JVM. A JVM built for Linux on ARM cannot run on Windows on x86, because it is a native program like any other.

So the portability promise, "write once, run anywhere", is delivered by having a different JVM everywhere and the same bytecode. Portability is bought with a platform-specific runtime, not by magic in the language.

How They Work Together

The full path from source to output:

1. You write Hello.java using the JDK.

2. javac, part of the JDK, compiles it to Hello.class as bytecode.

3. java, the launcher, starts a JVM.

4. The JVM loads Hello.class, verifies it, and links against the class libraries from the runtime.

5. The JVM interprets the bytecode, and its JIT compiler converts the hot paths to native code.

6. The garbage collector reclaims objects as the program runs.

Steps 1 and 2 need the JDK. Steps 3 through 6 need only a runtime. Every step after 2 works with bytecode, which is why a compiled .jar built on a developer's Mac runs unchanged on a Linux server.

Does the JDK Include the JRE?

Yes, in the sense that matters: a JDK contains everything needed to run Java, so installing a JDK gives you a working runtime and you do not need to install anything else.

What changed is the packaging. Java 8 and earlier physically shipped a jre subdirectory inside the JDK folder. From Java 11 that subdirectory is gone, and the runtime pieces live inside the JDK's module system instead. Nothing was removed in capability. The JDK still runs Java; it simply no longer contains a separately labelled copy.

You can check what you have:

java -version
javac -version

If both print a version, you have a JDK. If java works and javac reports "command not found", you have a runtime only, and you cannot compile.

Can You Use the JRE Without the JDK?

You can run Java programs with a runtime alone, and for Java 8 that meant installing a JRE. For anything newer, the equivalents are a JDK, or a runtime image built with jlink, or a container image based on a JRE-flavoured tag from a distribution such as Eclipse Temurin.

You cannot compile with a runtime alone. If a build tool reports that it cannot find javac or a "tools.jar", the cause is almost always a runtime-only installation where a JDK is required.

Why This Matters in Backend Work

The layering stops being trivia the moment you deploy something.

Container images. Building with a full JDK image and running the result on a smaller runtime image is a standard multi-stage Docker pattern, and it works precisely because the build output is portable bytecode. Our guide to Spring Boot with Docker walks through that build.

Version mismatches. UnsupportedClassVersionError at startup means the bytecode was compiled by a newer JDK than the JVM trying to run it. Newer JVMs run older bytecode; older JVMs cannot run newer bytecode.

Memory tuning. Heap sizing, garbage collector choice, and container memory limits are all JVM settings, not language settings. They are configured with flags passed to java, not written in your code.

Interviews. "Is the JVM platform-independent?" is asked constantly, and the answer above is the one interviewers are listening for. Our Java backend development guide covers what sits on top of these fundamentals, and backend interview questions collects the wider set with model answers.

Frequently Asked Questions

What is the difference between JDK, JRE, and JVM?

The JDK is a development kit that compiles and runs Java code. The JRE is a runtime that only runs it. The JVM is the engine inside the runtime that executes bytecode. They nest: the JDK contains a runtime, and the runtime contains a JVM.

Which one should I install?

A JDK. It includes everything a runtime does, plus the compiler and tools, and since Java 11 a standalone JRE is no longer offered by Oracle or most OpenJDK distributions anyway.

Is the JVM platform-independent?

No. The JVM is platform-dependent, built separately for each operating system and processor architecture. Java bytecode is the platform-independent part, and it is the same file everywhere.

Does the JDK include the JRE?

Functionally yes: a JDK can run Java programs without anything else installed. Java 8 and earlier shipped a visible jre subfolder inside the JDK; from Java 11 those runtime pieces live in the module system instead, with no separate folder.

What is JRE in Java in simple terms?

It is the runtime environment: a JVM plus the standard class libraries, which together are everything a compiled Java program needs to run. It cannot compile source code.

Why does my build fail with "javac: command not found"?

You have a runtime installed, not a JDK. Install a JDK and make sure JAVA_HOME points at it, then check javac -version prints a version.

What does UnsupportedClassVersionError mean?

The class file was compiled by a newer JDK than the JVM trying to run it. Either rebuild targeting the older version with --release, or upgrade the JVM on the machine that is running the code.

Summary

The JDK, JRE, and JVM are three layers of the same stack rather than three alternatives. The JDK compiles and ships tools, the JRE runs compiled code, and the JVM executes bytecode and manages memory. Each one contains the next.

Bytecode is what makes Java portable, and the JVM is the platform-specific piece that makes bytecode runnable. Install a JDK, because it contains everything, and because a standalone JRE has not been part of mainstream Java distributions since Java 11. When something breaks at startup, the error usually tells you which layer you are missing: a compiler complaint means no JDK, and a class-version complaint means a JVM older than the code it was handed.