JDK, JRE, and Java releases

Map the installed tools and runtime, read real version metadata, and distinguish feature releases, updates, and vendor support.

This is a fresh Java VM session. All starting files are supplied here; no notebook or earlier lesson is required. Work through the experiments, predict each result, and inspect what actually changed. Resetting or leaving discards guest files.

What is installed here?

A Java installation combines several ideas. The JVM executes bytecode. The JRE is the runtime concept: the JVM and libraries needed to run Java programs. The JDK includes runtime components and development tools such as javac, jshell, jar, and javadoc. You do not need a second installation simply because both java and javac are present.

Modern packaging varies. A JDK need not contain a nested jre/ directory, and a vendor need not distribute a separate JRE download. Use the actual files and tool paths as evidence rather than judging an installation by an old directory screenshot.

JAVA_HOME and PATH have different jobs

JAVA_HOME points to the installation root, here /opt/java. PATH tells the shell where to search for commands. command -v java identifies the command found by the shell; readlink -f resolves any symbolic links. Inspect both java and javac. Do not assume a shell command resolves inside JAVA_HOME just because the variable is set.

A runtime-only environment can launch compatible classes but cannot compile Java source without a compiler. An arbitrary folder called java is not evidence of a JDK. The executable tools and the distribution's release metadata give stronger evidence.

Read the installation map

The lab supplies the Zulu 27 distribution. Inspect these directories:

| Directory or file | What to look for | | --- | --- | | bin | Executable launchers and tools | | conf | Configuration files | | lib | Runtime implementation and module image | | jmods | Modules used by tools such as jlink | | include | Native interface headers | | legal | License and notice files | | release | Vendor, feature version, platform, module metadata |

Do not edit the installed JDK. Your notes and compilation outputs belong under ~/java-lab. The final installation map records a path and purpose for each item so that someone else can follow your observations.

Feature version, update, and support policy

Java feature releases normally arrive every six months, in March and September. A feature version such as 25 identifies a language and platform release. A maintenance version such as 25.0.1 identifies an update within that feature line. It does not mean a new feature release occurred.

Java 17 (September 2021), Java 21 (September 2023), and Java 25 (September 2025) are useful dated LTS examples. LTS is a vendor support policy, not another language or a special compilation mode. Support periods, licensing, and patch availability depend on the vendor and offering. The current Oracle roadmap is one vendor's policy; do not apply its dates automatically to Azul or another provider.

This lab runs Zulu 27, not a hidden JDK 25. Read its release file to identify the vendor and x86_64 architecture. A newer runtime does not make every source file compatible with an older release. The browser emulator's execution speed is distinct from the Java feature version.

Targeting an older release

The guest uses an interpreted Java 27 build, so compilation needs no interpreter option. Wait for the shell prompt before entering the next command.

javac --release 25 ReleaseCheck.java asks this installed compiler to use the source/API rules and class-file target for release 25. javap -verbose exposes the emitted class-file major version: 69 for Java 25. Running that class on Java 27 still reports runtime 27, because compilation target and executing JVM are separate facts.

The switch does not install Java 25 and does not test your application on an actual Java 25 JVM. It is a useful compatibility control; a real release workflow also tests on its supported runtimes. Here the small fixture only prints java.version, so the comparison stays easy to explain.

Make an installation handover

Create a short installation map and a release timeline. Each note should separate an observed value from an explanation: tool path, vendor, feature version, target release, update example, and the meaning of LTS. These notes are guest files for practice, and disappear when you leave or reset the lesson.

References: JDK directory structure, javac --release, and Oracle Java support roadmap.

java --version

javac --version

printf "%s\n" "$JAVA_HOME"

command -v java javac

readlink -f "$(command -v java)" "$(command -v javac)"

ls -d "$JAVA_HOME"/{bin,conf,lib,jmods,include,legal,release}

cat "$JAVA_HOME/release"

ls -l "$JAVA_HOME"/bin/{java,javac,jshell,jar,javadoc}

jshell --version

cd ~/java-lab

cat ReleaseCheck.java

javac --release 25 ReleaseCheck.java

javap -verbose ReleaseCheck | head -20

java ReleaseCheck

printf '%s\n' 'JAVA_HOME=/opt/java' 'bin: java runs bytecode; javac compiles source; jshell explores snippets' 'conf: configuration' 'lib: JVM and runtime modules' 'jmods: modules for tooling' 'include: native headers' 'legal: notices' 'release: vendor, version, architecture' > installation.txt

cat installation.txt

printf '%s\n' '17: September 2021; LTS example' '21: September 2023; LTS example' '25: September 2025; LTS example' 'Feature releases: normally March and September' '25.0.1: maintenance update within feature 25' 'LTS: vendor support policy, not a language mode' > releases.txt

cat releases.txt

grep -E "IMPLEMENTOR|JAVA_VERSION|OS_ARCH" "$JAVA_HOME/release"

You completed the tooling workflow using real commands and files. Explain each result before moving on; tool output is evidence, not a substitute for the Java rule behind it.

Enable JavaScript to run the live terminal and track your progress.