EasyJava#26 min readJul 11, 2026
Difference between JDK, JRE, and JVM.
practice
Hook: Think of Java like a car: the JVM is the engine, the JRE is the engine plus the parts needed to drive, and the JDK is the full garage with tools to build and fix the car.
Question: Difference between JDK, JRE, and JVM.
Answer: These are three layers of the Java platform. The JVM (Java Virtual Machine) is the runtime engine that executes Java bytecode. The JRE (Java Runtime Environment) is the JVM plus the standard libraries and files needed to run Java programs. The JDK (Java Development Kit) is the JRE plus developer tools like javac, jar, and javadoc for building Java applications.
Interview-Ready Answer: I explain it as three layers. The JVM is the piece that actually runs Java bytecode. The JRE is the JVM plus the core libraries needed to run apps, and the JDK is the full package for developers because it includes the JRE plus tools such as javac to compile code. A useful modern detail is that many Java 11+ distributions do not ship a separate end-user JRE anymore, so in practice people usually install a JDK and then build a smaller runtime if needed.
%22%20stroke%3D%22%234f46e5%22%20stroke-width%3D%221.5%22%2F%3E%3Ctext%20x%3D%22500%22%20y%3D%22308%22%20text-anchor%3D%22middle%22%20font-size%3D%2215%22%20font-weight%3D%22bold%22%20fill%3D%22%23ffffff%22%20font-family%3D%22Segoe%20UI%2C%20Arial%2C%20sans-serif%22%3EJava%20Stack%3C%2Ftext%3E%3C%2Fsvg%3E)
What each one means
Detailed Explanation: The simplest way to remember it is:
JVM= the machine that understands and runs bytecode (the portable instructions produced by the compiler).JRE= JVM + standard Java libraries + files needed to run programs.JDK= JRE + tools needed to develop programs.
Under the hood: what happens from source to running app
- You write
.javasource code. - The
javaccompiler from the JDK turns source into.classfiles containing bytecode. - The JVM starts, finds the main class, and the class loader loads the needed classes into memory.
- The bytecode verifier checks that the bytecode is safe and well-formed before execution.
- The JVM executes the bytecode using an interpreter and often a JIT compiler (just-in-time compiler, meaning it turns hot bytecode into native machine code while the program is running).
- Runtime services like the garbage collector (GC, the automatic memory cleaner) free memory no longer in use.
Comparison table
| Part | Main job | Contains | Can compile? | Can run? |
|---|---|---|---|---|
| JVM | Execute bytecode | Class loading, JIT, GC | No | Yes |
| JRE | Run apps | JVM + libraries | No | Yes |
| JDK | Build apps | JRE + tools | Yes | Yes |
When and why you use each one
- Use the JDK on a developer machine, CI server, or anywhere you need compilation, packaging, debugging, or docs generation.
- Use the JRE/JVM runtime when you only need to execute an already-built application.
- For production, teams often ship a trimmed runtime image instead of the full JDK to reduce size and attack surface; on Java 9+, tools like
jlinkmake that easier.
Performance and edge cases
- The JVM has startup overhead, but the JIT improves steady-state speed after it learns which methods are used often.
- Class loading cost is roughly proportional to the amount of class metadata and bytecode that must be loaded, but the big practical cost is usually startup and warm-up, not raw loading complexity.
- If a class is compiled with a newer Java version than the JVM supports, you can get
UnsupportedClassVersionError. - If you only have a runtime and no compiler,
ToolProvider.getSystemJavaCompiler()returnsnull, which is a classic sign that you are not on a full JDK. - Since Java 11, many distributions stopped shipping a separate consumer JRE, so the term still matters conceptually even though installations may look different.
Memory hook: Run, Run-with-libraries, Run-and-build: JVM runs bytecode, JRE runs with libraries, JDK runs and builds.
Real-world story: Imagine a checkout service for an e-commerce app. Developers build it with a JDK on their laptops, CI compiles it with javac, and production containers only need a runtime because they are just launching the already-compiled service. The JVM is the part inside the container that actually executes the bytecode for payment validation, discount calculation, and order placement.
What goes wrong when someone misunderstands the difference? A common outage is deploying a build compiled on Java 21 to servers still running an older Java 17 JVM. The service starts, then immediately crashes with UnsupportedClassVersionError in the logs, pods restart-loop, and users see checkout failures or long delays. Another failure is a team using JavaCompiler in production code, only to discover that the runtime image does not include compiler tools, so startup fails with a message like “No system Java compiler available.”
The lesson: the JDK is for creating Java software, the JRE is for running it, and the JVM is the execution engine underneath both.
Java
import javax.tools.JavaCompiler;
import javax.tools.ToolProvider;
import java.io.IOException;
import java.lang.reflect.Method;
import java.net.URL;
import java.net.URLClassLoader;
import java.nio.charset.StandardCharsets;
import java.nio.file.Files;
import java.nio.file.Path;
public class Main {
public static void main(String[] args) throws Exception {
System.out.println("Running on Java " + System.getProperty("java.version"));
System.out.println("JVM: " + System.getProperty("java.vm.name"));
// This API is only available when a full JDK is present.
// If it is missing, you are effectively on a runtime-only setup.
JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
if (compiler == null) {
System.out.println("No system Java compiler found.");
System.out.println("This usually means you are running on a JRE-like runtime, not a full JDK.");
return;
}
Path tempDir = Files.createTempDirectory("jdk-jre-jvm-demo");
Path sourceFile = tempDir.resolve("GeneratedHello.java");
// We generate a tiny class, compile it, and load it dynamically.
// That shows the JDK doing work the JVM alone cannot do.
String source = ""
+ "public class GeneratedHello {\n"
+ " public String greet() { return \"Hello from compiled bytecode!\"; }\n"
+ "}\n";
Files.writeString(sourceFile, source, StandardCharsets.UTF_8);
// -d makes the compiler put .class files in our temp directory.
int result = compiler.run(null, null, null, "-d", tempDir.toString(), sourceFile.toString());
if (result != 0) {
System.out.println("Compilation failed with exit code: " + result);
return;
}
try (URLClassLoader loader = URLClassLoader.newInstance(new URL[] { tempDir.toUri().toURL() })) {
Class<?> type = Class.forName("GeneratedHello", true, loader);
Object instance = type.getDeclaredConstructor().newInstance();
Method greet = type.getMethod("greet");
System.out.println("Loaded class: " + type.getName());
System.out.println("Invocation result: " + greet.invoke(instance));
}
// Edge case: cleanup is best-effort. The concept matters more than temp-file hygiene.
try {
Files.deleteIfExists(sourceFile);
} catch (IOException ignored) {
// Intentionally ignored.
}
}
}Follow-up & Tricky Questions:
- What is bytecode? Bytecode is the portable intermediate form produced by
javac. The JVM reads bytecode, which is why the same.classfile can run on different operating systems if the JVM version is compatible. - Why is Java called platform independent? Because source code compiles to bytecode, and the JVM abstracts away the CPU and OS details. The same class file can run on Windows, Linux, or macOS as long as there is a compatible JVM.
- What is the JIT compiler? It is the runtime compiler inside the JVM that turns frequently executed bytecode into native machine code. This gives Java a fast warm-up/steady-state balance instead of being purely interpreted.
- Can I run Java without a JDK? Yes, if you only need to execute an already-built program and the runtime is available. But you cannot compile source code or use JDK-only tools without the JDK.
- Is the JRE the same as the JVM? No. The JVM is the execution engine; the JRE is the JVM plus libraries and supporting files needed to run applications.
- Tricky: If I have a JDK, do I automatically have a separate JRE install? Not always in modern Java distributions. Conceptually the runtime is there, but many Java 11+ packages do not ship a separate consumer JRE download.
- Tricky: Can the JVM run source files directly? Not in the traditional model; it runs bytecode, not source. The source must be compiled first, although newer Java versions add convenience features for single-file source launch.
Common Mistakes:
- Mixing up JRE and JVM — correction: the JVM is only the execution engine; the JRE includes the JVM plus libraries.
- Saying the JDK is just a bigger JVM — correction: the JDK is the full development kit and includes compiler/tooling, not just runtime pieces.
- Claiming Java source runs directly on the JVM — correction: source is compiled to bytecode first, then the JVM runs the bytecode.
- Ignoring version compatibility — correction: a newer compiler can produce bytecode an older JVM cannot execute.
Memory Hook: JVM = runs, JRE = runs with libraries, JDK = runs and builds. If you can compile, you need the JDK; if you only execute, you need the runtime; the JVM is the engine inside both.
Cheat Sheet:
JVMexecutes bytecode.JRE= JVM + core libraries.JDK= JRE + developer tools.javaccomes with the JDK, not the JRE.- Java code is compiled to
.classbytecode before running. - Modern Java distributions often do not ship a separate standalone JRE.
Practice Tasks:
- Install a JDK and run
java -versionandjavac -version; notice both are present. - Temporarily point your IDE or terminal to a runtime-only setup and observe that compilation tools disappear.
- Compile a tiny class, inspect the generated
.classfile, and run it with thejavalauncher.