JDK Explained: Components, Setup Process, and Installation Guide

The JDK is the toolchain required to *build* Java software, as distinct from the runtime required to *run* it. That distinction used to be crisp, because you installed a JDK and a separate JRE. **It no longer is**, and this is the single most important thing to understand about the modern JDK.

Since JDK 11 the separate JRE distribution no longer exists. There is no JRE installer to download, because the runtime is already inside the JDK and the **module system** lets you carve out exactly the parts you need. Any tutorial telling you to "download the JRE separately" is describing a workflow that ended years ago.

WHAT PEOPLE STILL DRAW              WHAT IS ACTUALLY TRUE TODAY
   ┌────────────┐  ┌────────────┐      ┌──────────────────────────────┐
   │    JDK     │  │    JRE     │      │             JDK              │
   │ javac,jar  │  │  java      │      │  java, javac, jar, jshell    │
   │ javadoc    │  │  lib/*.jar │      │  jlink, jmod, jpackage, ...  │
   └─────┬──────┘  └─────┬──────┘      │                              │
         └──── contains ─┘              │  ~70 modules, incl. java.base│
              (true until 2018)         │  jlink builds a runtime image │
                                        └──────────────────────────────┘

The verifiable proof of this is on disk. Listing the contents of a real Temurin 17 installation shows there is no jre directory at all:

$ ls /tmp/jdkbin conf include jmods legal lib man NOTICE release

No jre/. What took its place is jmods, holding 70 module files, and the bin directory now carries 28 executables.

A modern JDK ships 28 command-line tools. They are worth knowing by category, because most people use four of them and have never heard of the rest.

Two entries on this list are the ones worth calling out for beginners, because neither appears in any "getting started" tutorial.

**jshell** is a REPL. It runs Java interactively with no project, no file, and no main method, which is the fastest way to check how a language feature actually behaves:

$ jshelljshell> int x = 40 + 2;
jshell> System.out.println("answer is " + x);
answer is 42jshell> /exit

**jlink** builds a custom runtime image containing only the modules you name. This replaced the JRE download entirely, and the size difference is dramatic. On this machine:

full JDK : 318 MBjlink image, java.base only : 37 MB

That 37 MB image is a genuinely working runtime. It contains two executables, java and keytool, it lists exactly one module, and it runs a compiled class:

$ ./myrt/bin/java --list-modulesjava.base@17.0.20.1$ ./myrt/bin/java -cp out Tinytrimmed runtime works

javac translates source into bytecode. The detail that matters for setup is **the release flag**, because it is what stops a build from silently producing class files a target machine cannot run.

javac --release 17 MyApp.java # bytecode targets Java 17

--release does two things at once: it sets the bytecode target version *and* restricts the API surface to that release's documented API. That second part is the valuable one. Without it, you can compile against newer APIs on a newer JDK and only discover at runtime that older machines lack the method.

The running JVM reports the highest class file version it accepts, which is a quick way to confirm what you actually have:

java.class.version = 61.0accepts class files up to major version 61

That value is 61.0, note the decimal. Parsing it with Integer.parseInt throws a NumberFormatException, which is a small trap the example for this topic hit and had to handle.

The most common setup failure is having two different JDKs on the PATH at once, so java comes from one install and javac from another. The symptom is confusing, because each command reports a version and they may not match.

java -version # runtime actually usedjavac -version # compiler actually usedwhich javawhich javac

Both must report the same version and the same directory. If they disagree, the fix is to put a single JDK/bin at the front of PATH, not to reinstall anything.

Note also that java -version writes to **stderr**, not stdout. That trips up scripts:

java -version 2>&1 | head -1 # correctjava -version | head -1 # prints nothing

This distinction trips people up constantly, and the two names being so similar is the reason.

The example demonstrates the difference directly, and the null is not a mistake:

java.home = /tmp/jdkJAVA_HOME env = null

java.home is always populated by the JVM. JAVA_HOME was never set in that shell, so it is null. Your code should never assume JAVA_HOME exists.

### The layout trap

java.home used to point at /jre, because the JRE was a nested subdirectory. **Since JDK 9 it points at the JDK root itself**, and that change broke a lot of build scripts that had hardcoded the extra segment. The example checks all three layouts live:

/lib exists = true/jre exists = false

If you maintain scripts that build paths from JAVA_HOME, this is the single most likely reason they break on a modern JDK.

JDK 9 replaced the old classpath-first design with the **module system**. The standard library was carved into about 70 modules, each with a declared dependency graph, and java.base sits at the root containing the fundamental classes.

You can see the boot layer at runtime, which the example does:

boot layer module count : 62first 8 :[java.base, java.compiler, java.datatransfer, java.desktop, java.instrument, java.logging, java.management, java.management.rmi]java.base present : true

62 modules are resolved into the boot layer at startup. The distribution ships 70 .jmod files, and jlink or --add-modules chooses how many actually load.

This design is what made the JRE unnecessary. Because the platform is modular and dependencies are declared, a runtime can be assembled mechanically from a module list, so jlink does it on demand instead of Oracle shipping a separate download.

The command is straightforward:

jlink --add-modules java.base \ --no-header-files --no-man-pages --compress=2 \ --output myruntime

Note that --strip-debug is commonly added for further size reduction, and it failed on this machine:

Error: java.io.IOException: Cannot run program "objcopy": error=2, No such file or directory

This is a real dependency, not a fluke. --strip-debug shells out to a platform objcopy, so it only works where one is installed. Dropping the flag produced a working 37 MB image. Worth knowing before you conclude your jlink setup is broken.

Trimming is genuinely enforced. A class that uses java.sql compiled fine, and jdeps reported its true dependency:

$ jdeps --print-module-deps NeedsSql.classjava.base,java.sql

Run on the trimmed runtime, it fails at the point of use:

NoClassDefFoundError: java/sql/Connection

That error is the module system doing exactly what it promises. A classpath-based runtime had no way to express this; the module graph knows the answer before the program starts.

One trap worth flagging: **jdeps --print-module-deps only sees what actually survived compilation.** A file that merely *imports* java.sql but never calls into it reports only java.base, because javac elides unused imports. Trust the dependency analyser on the compiled output, not on your reading of the source.

Since the licensing change in 2019, the JDK implementations are functionally equivalent, and Oracle's own JDK is no longer a special case. The differences that remain are support policy and release cadence.

**Choose an LTS release** for anything long-lived. LTS versions receive updates for years while feature releases receive roughly six months of support. Feature releases arrive every six months and are named after the year and the month sequence, so 17 was 2021, 21 was 2023, and 25 is 2025. Odd numbers are feature releases, and every fourth one is designated LTS.

As of this writing, **Java 25 is the current LTS and Java 27 the current feature release**. Everything measured in this topic was run on Temurin 17.0.20.1.

Follow this order and setup problems rarely occur.

Step 2 is the one people skip and the one that matters. A javac from a newer JDK sitting ahead of an older java on the PATH produces builds that compile cleanly and fail at runtime, which is an unpleasant way to discover the problem.

Every number in this article came from running commands against Eclipse Temurin 17.0.20.1, not from documentation.

The headline finding is the first pair. A 318 MB JDK contains a 37 MB working runtime, and the difference is exactly the code you were never going to use. That is the module system doing the job that a separate JRE download used to do, only better, and it is why the JRE is no longer something you install.