JDK, Runtime Images, and the JVM: Understanding Their Roles

Hello, and welcome to the first lesson. This module builds the runtime model needed for nearly every Java interview discussion: what Java installs contain, what actually runs an application, and why Java terminology can be confusing in modern releases.

With Node.js, installing a Node distribution normally gives you both the runtime and developer-facing tooling in one package. Java has a similar practical experience, but its vocabulary is more layered. By the end of this lesson, you should be able to distinguish the JDK, a Java runtime image, and the JVM precisely—and answer the common “JDK vs JRE vs JVM” interview question without relying on outdated terminology.

---

The three layers: toolkit, runtime, execution engine

A useful first approximation is:

Term	Primary responsibility	Typical contents
JDK	Develop, build, test, package, diagnose, and run Java	Runtime image plus development tools
Java runtime image	Provide everything needed to run a particular Java application	JVM, standard-library modules, configuration, native support files
JVM	Execute Java bytecode on a particular host platform	Class execution engine, memory management, garbage collection, JIT compiler, threading support

The relationship is one of containment, but the responsibilities matter more than the nesting diagram:

1. A JDK is what a developer installs to create Java software.
2. A runtime image is the deployable environment needed to execute Java software.
3. The JVM is the execution engine within that environment. It does not, by itself, supply the full standard Java API your application uses.

A key qualification: this picture is conceptually useful, but modern Java installations are modular rather than necessarily arranged as a separately installed “JRE inside a JDK.” That distinction is where interview answers often become imprecise.

---

The JDK: the developer’s distribution

JDK means Java Development Kit. It is the complete distribution used to develop Java applications. If you need to compile a .java source file, you need a JDK, because the compiler is a JDK tool.

Common JDK commands include:

Command	Responsibility
javac	Compiles Java source code into .class bytecode files
java	Launches a Java application using the runtime in the JDK
jar	Creates and manipulates Java archive files
javadoc	Generates API documentation from source comments
jdb	Java debugger
jcmd, jstack, jmap	Diagnostic and monitoring utilities

The JDK also supplies the Java platform APIs used by ordinary applications: classes such as String, List, Map, Files, and HttpClient. Those APIs are available both when compiling and when running an application.

For example, when you issue:

javac Hello.java

you invoke a JDK development tool. When you issue:

java Hello

you use a launcher that starts the Java runtime and, ultimately, the JVM.

Interview question: What is the JDK?

Answer:
The JDK is the full Java development distribution. It includes a runtime capable of executing Java applications and developer tools such as the javac compiler, debugger, documentation generator, packaging tools, and diagnostic utilities. Developers need a JDK to compile and build Java code; a runtime-only deployment does not need those development tools.

Interview question: Can a Java application run with only a JDK installed?

Answer:
Yes. A JDK includes a runtime, so it can run applications as well as build them. This is common in development and is also sometimes used in production for operational simplicity, although it may include tools and modules that the deployed application does not require.

---

The Java runtime image: what an application needs to execute

Historically, interviewers often described the JRE, or Java Runtime Environment, as:

JVM plus the standard Java class libraries and supporting files.

That definition remains conceptually sound. An application needs more than a JVM instruction executor. Consider code that uses String, ArrayList, file I/O, dates, networking, or database APIs. Those classes and their supporting runtime facilities must be present too.

However, modern Java changed the packaging model.

Beginning with Java 9, Java’s platform was organized into modules, and Oracle no longer distributes a separate consumer JRE in the traditional way. Instead, modern Java uses the broader and more accurate term runtime image:

• A full JDK contains a runtime image for running Java.
• A deployment may use a custom runtime image containing only the Java modules an application needs.
• Some JDK vendors still offer packages labeled “JRE,” but you should not assume a separate JRE installation exists or is necessary.

A runtime image contains, at minimum:

• a JVM implementation appropriate to the host system;
• selected Java platform modules, such as java.base;
• standard-library classes and resources;
• launcher and configuration files;
• native libraries and other files the JVM needs.

The tool jlink, included with the JDK, can produce a smaller runtime image for a modular application. For a backend service, teams often deploy a JDK-based container image, but a purpose-built runtime image can reduce size and narrow the installed platform surface.

The critical distinction is this:

A runtime image is an environment for running an application; the JDK is a distribution for developing and operating on Java applications.

Interview question: What is the difference between a JRE and a runtime image?

Answer:
A JRE is the older, familiar name for a Java runtime environment consisting conceptually of the JVM plus Java libraries and supporting files. In modern Java, especially since Java 9, “runtime image” is more precise because runtimes are modular and can be custom-built with tools such as jlink. A separate JRE install is no longer a universal feature of JDK distributions.

Interview question: Does a Java application need every Java library module at runtime?

Answer:
No. It needs the modules required by the application and its dependencies. Every ordinary Java application requires foundational functionality from java.base, but it may not need modules for desktop UI, SQL, management, or other optional platform capabilities. A custom runtime image can include only the required modules.

---

The JVM: the bytecode execution engine

JVM means Java Virtual Machine. It is a specification for a virtual execution environment, as well as the practical implementation that executes Java bytecode on a specific host platform.

The JVM’s central responsibility is to load and execute compiled .class files. It does not execute Java source code directly, and it does not independently provide the complete java.util or java.net libraries your application imports.

At runtime, a JVM implementation handles major responsibilities such as:

• executing bytecode, initially through interpretation and later with optimized native code where appropriate;
• managing object memory and garbage collection;
• creating and coordinating Java threads;
• enforcing important runtime type and access checks;
• interacting with the operating system for files, networking, timing, native memory, and process-level services;
• translating Java-level behavior to the CPU and operating system of the host machine.

This is why the same compiled Java bytecode can run on different systems: the application’s .class files are portable, while the JVM implementation is built for the particular platform on which it runs.

For example, a Linux server and a Windows development machine require different JVM binaries. But both JVMs can execute the same application bytecode, assuming compatible Java versions and dependencies.

Interview question: Is the JVM platform-independent?

Answer:
No. Java bytecode is largely platform-independent, but the JVM implementation is platform-specific. A JVM built for Linux differs from one built for Windows or macOS, and its native code must match the processor architecture. The JVM is precisely the layer that lets portable bytecode execute on a particular operating system and CPU.

Interview question: Is the JVM the same thing as the Java standard library?

Answer:
No. The JVM executes bytecode and provides runtime services such as memory management and thread execution. The Java standard library consists of APIs and implementation classes such as String, List, Map, and Files. A Java runtime image combines the JVM with the necessary library modules and support files.

Interview question: Does the JVM compile Java source code?

Answer:
No. The JDK’s javac compiler compiles Java source code into bytecode. The JVM executes that bytecode. At runtime, a JVM may use just-in-time compilation to convert frequently executed bytecode into optimized native machine code, but that is different from compiling .java source files with javac.

---

A reliable way to answer the classic interview question

When asked, “Explain JDK, JRE, and JVM,” avoid a memorized one-line answer. Use a responsibility-first explanation:

The JDK is the developer toolkit: it includes the compiler, debugger, packaging and diagnostic tools, plus a runtime.

A Java runtime image, traditionally called a JRE, contains the JVM, Java library modules, and support files required to run an application. In modern Java, it can be modular and custom-built rather than a separately installed JRE.

The JVM is the platform-specific execution engine within that runtime. It loads and executes bytecode and manages runtime services such as memory, garbage collection, and threads.

Then add this short operational distinction:

• Building from source: requires a JDK.
• Running a built application: requires a compatible runtime image.
• Executing bytecode within that runtime: is the JVM’s job.

This answer is accurate for modern Java while still recognizing the terminology an interviewer is likely to use.

---

Common interview traps

“The JDK contains a JRE, which contains a JVM.”

This is a useful historical and conceptual shorthand, but incomplete for current Java. Say that the JDK includes a runtime, and explain that modern JDKs use modular runtime images. Avoid claiming that every modern Java installation has a separately distributed jre/ directory.

“The JVM converts Java directly into machine code.”

Not quite. A Java compiler first transforms source code into bytecode. At runtime, the JVM executes bytecode through interpretation and may compile frequently executed code into native machine code using JIT compilation. The detailed execution path is the focus of the next lesson.

“Install a JRE for production and a JDK for development.”

This can be true in a broad sense, but it is not a universal deployment rule today. Production systems may run with a custom runtime image, a vendor-provided runtime, or a full JDK. The correct choice depends on deployment needs, image size, diagnostics, operational policy, and vendor support.

“JDK, JRE, and JVM are different names for Java.”

They are different layers with different jobs. The JDK is a toolchain, the runtime image is an application execution environment, and the JVM is the engine that executes bytecode.

---

A compact recall card

If the question mentions...	Think...
javac, jar, javadoc, debugging tools	JDK
Java APIs plus everything necessary to launch an application	Runtime image
Bytecode execution, garbage collection, JIT compilation, thread execution	JVM
A separately installed “JRE”	Legacy terminology or a vendor-specific runtime package; clarify the modern runtime-image model

---

The essential takeaway is that the JDK builds and supports development, a runtime image supplies the application’s executable environment, and the JVM executes bytecode and provides core runtime services. In modern Java, “JRE” remains useful interview vocabulary, but “runtime image” better describes how Java is packaged and deployed after Java 9.

Next, we will follow a Java program more closely: from .java source through compilation into bytecode, then through class loading, verification, interpretation, and JIT compilation.