JDK vs JRE vs JVM: Differences Explained

They are three nested things, not three competing products. The JVM is the virtual machine: the piece of native code that loads your compiled class files, manages memory, and translates bytecode into operating system calls. The JRE is the JVM plus the class libraries it needs to run a program — the java.base module, the collection classes, the networking stack. The JDK is the JRE plus the development tools: javac, javadoc, jar, jlink, jpackage, the debugger front-ends and the source-level tooling.

So the relationship is JDK contains JRE contains JVM. A server that only runs a pre-built artifact needs a runtime environment, which in modern Java means a JDK image with the compiler stripped, or a custom runtime image produced by jlink.

Which one does a server need?

Only the runtime part. Shipping javac onto a production host enlarges the image and increases attack surface for no benefit. Practically, that means either a jlink-produced runtime image containing just the modules you use, or a base image with the JDK from which you remove the compiler.

Two details worth stating in an interview. First, the JRE used to be a separate downloadable artifact; there is no longer a standalone JRE, because jlink lets you assemble exactly the runtime you need from modules. Second, the compiler is not needed at runtime, but the class libraries are — and the JVM version must be at least as new as the class-file version your compiler produced.

Only the JVM can be out of step, because the JVM is the thing that reads class files. Each class file records the major version it was compiled for, and a JVM refuses to load a class whose major version is newer than it understands. Compiling with a newer compiler and running on an older JVM produces exactly the error you quoted: the class file records a major version that the older runtime does not understand.

From inside a running program you can interrogate the JVM directly with the system properties, which is the quickest way to answer 'what am I actually running on' during an incident.

public class Main {
    public static void main(String[] args) {
        System.out.println("java.version      : " + System.getProperty("java.version"));
        System.out.println("java.vm.name      : " + System.getProperty("java.vm.name"));
        System.out.println("java.vm.version   : " + System.getProperty("java.vm.version"));
        System.out.println("java.spec.version : " + System.getProperty("java.specification.version"));
        System.out.println("java.home         : " + System.getProperty("java.home"));
    }
}

From a shell, the equivalent commands are java -version for the runtime and javac -version for the compiler. If java -version is not found but your application starts, you are on a JRE-style runtime image with no compiler, which is exactly what you want in production — so the fix is not to install a JDK but to align the class-file version with the runtime, using javac --release 11 or the matching toolchain.

The last detail: the error names the class that failed first, and the message states the exact major version mismatch. Read it — it usually saves an hour of guessing.

The reason is modularity. The runtime used to be a single monolithic artifact with every library from the JDK bundled in, whether you used it or not. Module system work made it possible to describe exactly which pieces of the runtime an application needs, and jlink uses that description to produce a trimmed runtime image containing only those modules. A separate JRE download became pointless the moment you could build your own, so Oracle stopped publishing one.

What changed in practice

Docker images are the biggest ripple. The old pattern was a two-stage build — copy a JRE into the final image, copy your jar in. The modern pattern is a single-stage build on a JDK base image, then a jlink step that assembles a runtime directory holding just the modules your application touches, and a final image that copies only that directory. The result is often a fraction of the previous size.

CI pipelines face the mirror image of the problem. Build agents need the full JDK because they must compile; test containers often need nothing more than a runtime; and some pipelines that used to cache a JRE tarball now cache a jlink output instead.

Long-term support is the subtle part. Because the standalone JRE disappeared, support policies are now expressed in terms of JDK releases and vendor distributions. A team on an old Long Term Support release keeps the compiler in the image and accepts the extra size, or maintains a jlink script that they re-run whenever they bump the base image. The interview answer is short: the JRE was retired so that runtimes could be composed from modules instead of shipped as one fixed binary.