JDK, JRE, and JVM are often used as if they were interchangeable, but they're not. The three terms describe distinct components that fit inside each other like nesting dolls. Knowing which one does what clarifies what to install, why a .class file runs on a different machine, and what javac is actually doing.

The three pieces form a clean hierarchy. The JVM is the smallest, most focused piece: the engine that runs Java bytecode. Wrap it with the standard libraries Java programs depend on, and you get the JRE, the runtime environment. Wrap that with the tools you need to write and compile Java code, and you get the JDK, the development kit.

Read it from the inside out. Running a Java program requires a JVM. Running a real Java program (one that uses String, ArrayList, file I/O, and so on) also requires the standard libraries; the standard libraries together with the JVM make up the JRE. Writing and compiling Java code requires the JDK, which bundles the compiler and other tools on top of the JRE.

The relationship is strict containment: JDK ⊃ JRE ⊃ JVM. The next three sections look at each piece in turn.

The JVM is the engine that runs Java bytecode. Compiling a Java file produces a .class file full of bytecode instructions, not native CPU instructions. The JVM reads those instructions and executes them on the actual hardware.

That indirection is what makes Java "write once, run anywhere." A .class file does not know whether it will run on a Mac, a Linux server, or a Windows laptop. The JVM does. There is a different JVM build for each operating system and CPU architecture, and each one translates the same bytecode into instructions its hardware understands.

A useful distinction: bytecode is portable, but the JVM itself is platform-specific. Applications don't ship a JVM with them; they assume the user already has one for their platform, and they ship the bytecode.

A JVM has three main internal areas:

The shape is: bytecode in, native execution out, with memory areas in between.

The JVM on its own isn't enough to run a real Java program. The moment code uses System.out.println, String, ArrayList, or reads a file, it's calling into Java's standard libraries. Those classes have to come from somewhere.

The JRE is exactly that bundle: a JVM plus the standard class libraries (java.lang, java.util, java.io, java.net, and the rest of the Java SE platform). It's the minimum environment needed to run a finished Java application.

One historical wrinkle. Up through Java 8, Oracle published a separate JRE download for end users who only needed to run Java programs, not develop them. Starting with Java 11, Oracle stopped distributing a standalone JRE. The JDK now ships everything; for a smaller runtime than the full JDK, the jlink tool (included in the JDK) builds a slim runtime image containing only the modules an application actually uses.

In modern Java, "install a JRE" is not a step one does from Oracle. Either install the full JDK, or use jlink to produce a custom runtime tailored to a specific application.

The JDK is what developers install. It contains the JRE (so it can run programs) plus the tools needed to write, compile, and inspect Java code. Writing Java requires the JDK.

The headline tools in the JDK:

The two most-used tools are javac and java. The split between them maps cleanly onto the JDK / JRE split: javac is a development tool (JDK-only), and java is a runtime tool (ships in the JRE as well).

In short: javac compiles, java runs.

A side-by-side view shows the difference. Each row is one of the three components, with what it contains, when it's needed, and which tools live there.

A few notes on the table:

A small check on the portability story. The same Welcome.java source compiles to the same Welcome.class everywhere:

Compile this on a Mac with javac Welcome.java, then copy the resulting Welcome.class to a Linux server, run java Welcome there, and the output is the same. The bytecode didn't change. The JVM underneath it did.

Java is built on an open-source codebase called OpenJDK. That's the reference implementation, and almost every available JDK is built from it. Multiple "vendors" exist because different organizations build, test, and support their own packaged versions of OpenJDK.

The common ones:

For learning Java, any of these works. They all run the same bytecode and pass the same compatibility tests. The differences mostly come down to licensing terms, long-term support windows, and which company ships security patches.

"The JDK" isn't one product. It's a category, and the choice is which vendor to install.

The short answer is almost always "install the JDK." A few common situations:

In practice, the choice is between two options: install a full JDK (the normal case) or build a slim custom runtime with jlink (the production-shipping case). The standalone-JRE option that older tutorials sometimes mention is not part of modern Java.