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

Java has three layers. Each one has exactly one responsibility.

• JVM is the engine that runs your compiled code.
• JRE is the engine plus all the standard library classes your program needs.
• JDK is everything in the JRE plus the tools you need to write and compile code.

They are nested like boxes inside boxes. The JDK is the biggest box. Open it and you find the JRE. Open the JRE and you find the JVM.

What is the JVM?

The JVM stands for Java Virtual Machine. It is a program that reads compiled Java bytecode and runs it on your computer.

When you write Java code, you do not write instructions for your specific CPU. Instead, the Java compiler produces .class files containing bytecode, which is a set of instructions that any JVM can understand. The JVM then translates those instructions into native machine code for whatever operating system it is running on.

The JVM handles several important jobs:

• Class loading reads your .class files from disk and loads them into memory.
• Bytecode verification checks that the loaded code is safe and properly structured before running it.
• Memory management allocates space on the heap for objects and on the stack for method calls.
• Garbage collection automatically frees memory from objects your program no longer uses.
• JIT compilation detects code that runs frequently (hot code) and compiles it directly to native machine code so it runs faster.

The JVM is defined by a specification, not by a single product. HotSpot from Oracle and OpenJ9 from Eclipse are two popular implementations. Both follow the same specification and run the same bytecode, but they use different garbage collection algorithms and JIT strategies under the hood.

What is the JRE?

The JRE stands for Java Runtime Environment. It is the JVM plus everything a Java program needs to run.

The JVM alone can execute bytecode, but your program also needs the standard library classes. When you write String name = "Pankaj" or List numbers = new ArrayList<>(), those classes come from the JRE's standard libraries. Without the JRE, the JVM would have an engine but no fuel.

The JRE includes:

• The JVM itself.
• Core libraries like java.lang, java.util, java.io, java.math, and java.time.
• Security policy files, timezone data, and character encoding tables.
• The java command that starts the JVM.

The JRE cannot compile source code. It can only run programs that have already been compiled into .class files.

What is the JDK?

The JDK stands for Java Development Kit. It contains everything in the JRE plus the tools a developer needs to build Java software.

The most important tool in the JDK is javac, the Java compiler. It reads your .java source files and produces .class bytecode files. Without javac, you cannot turn your code into something the JVM can run.

Other JDK tools include:

• jar packages your compiled classes into a single .jar archive for distribution.
• javadoc generates HTML documentation from comments in your source code.
• jdb is the Java debugger for stepping through code.
• jshell is an interactive console where you can try out Java code without creating a file (available from Java 9).
• jlink builds a custom runtime image containing only the modules your application needs (available from Java 9).
• javap disassembles .class files so you can inspect the bytecode.

You can check which tools are available by running this in your terminal:

# Check if you have the JDK (javac is a JDK-only tool)
javac -version

# Check which JVM and Java version you have
java -version

Why does Java have three separate layers?

The separation exists because different people need different things.

A developer writing code needs the compiler, the debugger, and the packaging tools. A production server running the compiled application does not need any of those tools. It only needs the JVM and the standard libraries to execute the bytecode.

By separating the layers, Java allows you to deploy only what is necessary. This matters for:

• Container size. A Docker image with just the JRE is 200+ MB smaller than one with the full JDK.
• Security. Fewer tools on a production server means a smaller attack surface. An attacker who gains access to a server with only the JRE cannot compile or debug code on that machine.
• Startup time. Smaller runtime images load faster.

How does code travel from writing to running?

Here is the complete journey of a Java program from source code to execution:

1. You write TransferDemo.java in a text editor or IDE.
2. You run javac TransferDemo.java. This is a JDK tool. It reads your source code and produces TransferDemo.class containing bytecode.
3. You run java TransferDemo. The java command is part of the JRE. It starts the JVM.
4. The JVM's class loader finds TransferDemo.class on the classpath and loads it into memory.
5. The bytecode verifier checks that the loaded code is safe.
6. The interpreter begins executing bytecode instructions one by one.
7. When the JVM detects that a method is called frequently, the JIT compiler compiles that method to native machine code so future calls run at full hardware speed.
8. While the program runs, the garbage collector periodically frees memory from objects that are no longer reachable.

// You can check which JVM is running your program
public class CheckRuntime {
    public static void main(String[] args) {
        System.out.println("JVM: " + System.getProperty("java.vm.name"));
        System.out.println("Vendor: " + System.getProperty("java.vm.vendor"));
        System.out.println("Version: " + System.getProperty("java.version"));
        System.out.println("Home: " + System.getProperty("java.home"));
    }
}

JVM: OpenJDK 64-Bit Server VM
Vendor: Eclipse Adoptium
Version: 17.0.9
Home: /usr/lib/jvm/temurin-17-jdk

Who needs which one?

The rule is simple:

• If you write Java code, you need the JDK. It gives you the compiler and all the development tools.
• If you build Java code on a CI/CD server, that server needs the JDK because it runs javac and jar during the build.
• If you only run a compiled Java application, you need the JRE or a custom runtime image. You do not need the compiler or debugger.

In practice, most developers install the JDK on their machine and never install the JRE separately, because the JDK already contains the JRE.

What changed after Java 11?

Before Java 11, Oracle shipped two separate downloads: the JDK for developers and the JRE for end users.

Starting with Java 11, Oracle stopped publishing a standalone JRE. If you need a runtime without the development tools, you use jlink to build a custom image:

# Create a slim runtime with only the modules your app uses
jlink --add-modules java.base,java.sql,java.logging \
      --output my-app-runtime

# The result is a self-contained runtime, often 40-60 MB
# instead of the 300+ MB full JDK

This change encourages developers to ship only what their application needs. The result is smaller Docker images, faster startup times, and a smaller attack surface in production.

What should a senior engineer know?

• HotSpot vs OpenJ9. Both implement the JVM spec. HotSpot focuses on peak throughput with its C2 JIT compiler. OpenJ9 focuses on fast startup and lower memory footprint. Your compiled .jar runs on both without any changes.
• JIT compilation tiers. HotSpot uses two compilers internally. C1 compiles quickly with basic optimizations. C2 compiles slowly but produces highly optimized native code. Hot methods start on C1 and get promoted to C2 automatically.
• The classloader chain. Bootstrap ClassLoader loads core classes like java.lang.String. Platform ClassLoader loads standard extensions. Application ClassLoader loads your application code. Understanding this chain helps you debug ClassNotFoundException and NoClassDefFoundError.
• GraalVM. A newer JVM implementation that supports ahead-of-time compilation into native binaries. This eliminates JVM startup time entirely, making it popular for serverless functions and CLI tools.
• Module system (Java 9+). The JDK itself is divided into modules like java.base, java.sql, and java.desktop. The jlink tool uses this module structure to create custom runtimes containing only the modules your application depends on.