JDK vs JRE in Java: Differences, Roles, and When to Use Each

By the end of this page, you will understand what the JDK and JRE are, how they relate to each other, and why the distinction mattered historically. You will also learn what tools the JDK adds beyond the JRE, when developers install each in practice, and how modern Java distributions have changed the way this is packaged.

The core idea is simple:

• JRE = everything needed to run a Java program
• JDK = everything needed to develop and run Java programs

Historically, the JRE contained the Java Virtual Machine (JVM) plus the standard libraries and supporting files required to execute Java applications.

The JDK included:

• the JRE
• the Java compiler javac
• debugging and diagnostic tools
• packaging and development utilities such as jar, javadoc, and others

So the relationship was usually:

• JDK = JRE + development tools

Why this matters

When you write Java code, the source files like Hello.java must be compiled into bytecode like Hello.class. That compilation step requires tools from the JDK, especially javac.

When you only want to execute already-compiled Java code, a JRE was historically enough.

Modern context

In older Java setups, it was common to install a JRE on machines that only needed to run Java applications, and a JDK on developer machines.

Today, with modern OpenJDK-based distributions, a separate end-user JRE is often not distributed in the same way. In practice, developers usually install a JDK, and deployment may use:

• the full JDK
• a slim runtime image
• a container image with only what the app needs

So the conceptual difference is still important for learning Java, even though the packaging model has changed.

Think of it like a kitchen:

• The JRE is a prepared kitchen where you can heat and serve food.
• The JDK is the full kitchen with cooking tools, knives, oven, recipe books, and prep space.

If someone gives you a finished meal, the smaller setup is enough to serve it.

If you want to create the meal yourself, you need the full kitchen.

In Java terms:

• running a program = serving the meal
• compiling and building a program = cooking the meal

So:

• JRE for running
• JDK for building and running

In Java, source code is written in .java files and compiled into .class files.

Example Java program

public class Hello {
    public static void main(String[] args) {
        System.out.println("Hello, Java");
    }
}

Compile with the JDK

javac Hello.java

This produces:

Hello.class

The javac compiler is part of the JDK, not the historical standalone JRE.

Run the program

java Hello

This starts the Java runtime and executes the bytecode.

What this shows

• To compile Java source code, you need the JDK.
• To run compiled bytecode, you need a Java runtime.
• Historically, that runtime was commonly installed as a JRE.
• In modern setups, the runtime often comes from a JDK installation or a custom runtime image.

Common tools associated with the JDK

javac    # compiler
java     # launcher/runtime
jar      # package classes into JAR files
javadoc  # generate documentation
jdb      # debugger

These are development-oriented tools, which is why the JDK is the full toolkit.

Consider this file:

public class SumDemo {
    public static void main(String[] args) {
        int a = 2;
        int b = 3;
        int total = a + b;
        System.out.println(total);
    }
}

Step 1: Write the source code

You create a file named SumDemo.java. This is human-readable Java source code.

Step 2: Compile the source code

javac SumDemo.java

What happens:

• javac reads the source code
• it checks for syntax errors
• it translates the code into Java bytecode
• it writes the result to SumDemo.class

This step requires the JDK.

Step 3: Run the bytecode

java SumDemo

What happens:

• the Java launcher starts the runtime
• the JVM loads SumDemo.class
• main is called
• a becomes 2
• b becomes 3
• total becomes 5
• System.out.println(total) prints 5

Output

5

Key takeaway

• Compiling uses JDK tools.
• Running uses the Java runtime.
• Historically, the runtime was distributed separately as the JRE.

Here are common situations where this distinction matters.

1. Developer workstation

A software developer writing Java code needs:

• a compiler
• build tools
• debugging tools
• the ability to run the app locally

So they install a JDK.

2. Running an existing desktop application

Historically, if a user only needed to run a Java application and not build one, a JRE could be enough.

Example:

• running a Java-based reporting tool
• launching an old enterprise desktop app

3. CI/CD build server

A build server compiles, tests, and packages Java applications. It needs the JDK.

Example tasks:

• javac
• Gradle or Maven builds
• test execution
• JAR creation

4. Production deployment

Modern production systems often avoid installing a broad system-wide JRE. Instead they use:

• a JDK-based container image
• a minimal runtime image
• a custom Java runtime bundled with the app

5. Education and local learning

If you are learning Java today, you almost always install a JDK, because it covers both development and execution.

In real projects, developers rarely think in terms of "I only need a JRE" during daily work. Instead, they think in terms of build environments and runtime environments.

Common patterns in real codebases

• Local development uses a JDK
• Build pipelines use a JDK
• Production uses a runtime suited to deployment needs

Typical workflow

1. Write Java code
2. Compile and test using a JDK
3. Package the app with Maven or Gradle
4. Deploy using a JDK or a smaller runtime image

Related tooling patterns

Validation during build

The JDK enables compile-time checks:

• syntax checking
• type checking
• annotation processing

This helps catch errors early.

Debugging and diagnostics

Teams use JDK tools for:

• debugging local issues
• inspecting threads and memory
• generating documentation

Containerized deployments

A common modern approach is:

• build the application in one container stage using a JDK
• run the final application in a smaller runtime-focused image

This reflects the same old idea behind JDK vs JRE: build tools vs runtime needs.

Practical rule

If a machine needs to compile Java code, it needs a JDK. If it only needs to execute Java code, it needs a Java runtime.

1. Thinking JDK and JVM are the same thing

They are not the same.

• JVM: the virtual machine that executes Java bytecode
• JRE: JVM + libraries needed to run Java programs
• JDK: JRE + development tools

2. Expecting javac to exist when only a runtime is installed

Broken expectation:

javac Hello.java
# command not found

Why it happens:

• javac is a development tool
• historically, it was part of the JDK, not the standalone JRE

How to avoid it:

• install a JDK when writing or building Java code

3. Assuming the old JRE/JDK packaging still applies everywhere

Beginners often read older tutorials and expect to download a separate JRE for every setup.

How to avoid it:

• understand the concept historically
• check how your current Java distribution packages runtime and tools

4. Confusing source code with bytecode

Broken idea:

• "The JRE runs .java files directly in the traditional compile-then-run model."

Usually, the normal flow is:

• .java source is compiled into .class bytecode
• the runtime executes the bytecode

5. Installing more than needed on deployment machines without thinking

This is not always wrong, but it can be unnecessary.

How to avoid it:

• use a full JDK where building is required
• use a leaner runtime approach in production when appropriate

JDK vs JRE

Historical view vs modern view

• JVM: runs Java bytecode
• JRE: JVM + runtime libraries
• JDK: JRE + compiler and developer tools

Quick rule

• Need to write, compile, debug, or build Java? Use a JDK.
• Need to run Java code only? You need a Java runtime.

Classic relationship

JDK = JRE + development tools
JRE = JVM + runtime libraries

Common JDK tools

javac   # compile source code
java    # run Java programs
jar     # create/read JAR archives
javadoc # generate docs
jdb     # debugger

Typical workflow

javac Hello.java
java Hello

Important modern note

• Older tutorials often separate JDK and JRE clearly.
• Modern OpenJDK distributions are often JDK-centered.
• The concept still matters, even if the packaging is different today.

Memory aid

• JRE = run
• JDK = develop + run

Is the JDK the same as the JRE?

No. Historically, the JDK included the JRE plus tools for development such as javac.

Do I need a JDK to run Java programs?

Not always in theory. To run Java code, you need a Java runtime. Historically that was often a JRE. In modern practice, many people install a JDK because it already includes what they need.

Do I need a JDK to compile Java code?

Yes. Compiling Java source code requires tools such as javac, which are part of the JDK.

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

The JVM executes bytecode, the JRE provides the runtime environment, and the JDK provides the runtime plus development tools.

Why do modern tutorials often tell me to install only a JDK?

Because modern Java distributions commonly focus on the JDK, and it covers both development and runtime needs.

Can production servers use a JDK?

Yes. Many deployments run on a JDK or a runtime derived from it. The choice depends on deployment size, security, and operational needs.

Is a separate JRE still commonly installed today?

Less commonly than in the past, especially in the OpenJDK ecosystem. The idea remains important, but packaging has changed.

• JVM — the execution engine underneath Java runtime behavior.
• Java bytecode — compiled output that the JVM executes.
• javac — the Java compiler provided by the JDK.
• Maven — a common Java build tool that typically relies on a JDK.
• Gradle — another build automation tool used in Java projects.
• JAR files — packaged Java applications and libraries.
• Class files — compiled Java bytecode files such as .class.
• OpenJDK — the standard open-source Java platform in modern use.
• Java installation and PATH — important for running java and javac commands correctly.