Install JDK 25 and choose a JDK build

To write Java you install a JDKJDK: The Java Development Kit: a JVM, the standard library and the tools for writing Java, among them the compiler javac, the java launcher, the disassembler javap and JShell. More in “What Java is, how it runs and where it is used”, and for this track that means JDK 25. Once it is installed, two commands tell you whether it worked: java -version and javac -version must both report 25. Several vendors publish builds of JDK 25, and every one of them runs the same programs. What sets them apart is the licence and how long each keeps sending updates, so those two facts decide which build you install. For learning, for college labs and for most projects, Eclipse Temurin 25 from the Adoptium project is a sound choice: it is open source, costs nothing, receives updates until at least 2031, and it is the JDK that this track’s examples run on. The last step is to make your terminal, your IDE and your build tool use the same JDK, through PATHPATH: An environment variable that lists folders in order. A terminal runs the first program of the name you type, such as java or javac, that it finds in those folders., JAVA_HOMEJAVA_HOME: An environment variable that names the folder of a JDK, the one that holds bin. Build tools such as Maven and Gradle use the JDK it names before the java found on PATH. or a version pinned for each project.

Builds of JDK 25 differ in licence and updates, not in behaviour

All of these builds come from the OpenJDKOpenJDK: The open-source project whose JDK releases are the reference implementation of each Java SE version. Eclipse Adoptium (Temurin), Oracle and other vendors build their JDKs from its source code. More in “What Java is, how it runs and where it is used” source code. These three are the ones you are most likely to meet:

• Temurin 25, built by the Adoptium project of the Eclipse Foundation. Its licence is the GPL, version 2, with the Classpath Exception: open source, with no fee. It receives updates until at least 2031. It suits learning, college labs, most teams and CI servers.
• Oracle JDK 25, built by Oracle. It comes under Oracle’s No-Fee Terms and Conditions until one year after JDK 29 ships; later updates come under Oracle’s OTN licence. It suits organisations that use Oracle’s own JDK, often with an Oracle support contract.
• OpenJDK 25 from jdk.java.net, plain OpenJDK builds that Oracle publishes. The licence is the same as Temurin’s, but updates stopped when JDK 26 replaced it, and the page now marks JDK 25 as superseded. It suits only trying the newest feature release during its six months.

The licence terms matter more than they first appear to. Since JDK 17, Oracle’s support roadmap has offered each LTS release of Oracle JDK at no cost to all users until one year after the next LTS appears. After that, new updates of that release come under the Oracle Technology Network (OTN) licence, which allows use at no cost only for personal and development purposes. The roadmap moves the updates of Oracle JDK 21 to the OTN licence once its overlap year with JDK 25 is over, and plans the same for Oracle JDK 25 a year after JDK 29. So on a college lab computer or at work, check which build is installed before you rely on it.

Temurin avoids that question. The Adoptium FAQ gives its licence as the GNU General Public License, version 2, with the Classpath Exception, says the builds cost nothing, and states that every Temurin release has passed Oracle’s Java Compatibility Kit, the test suite that checks a build against the Java SEJava SE: Java Platform, Standard Edition: the specification of the language (the JLS), of class files and the JVM (the JVMS) and of the standard API, one version for every feature release, such as Java SE 25. More in “What Java is, how it runs and where it is used” specification. Microsoft, Azul, Red Hat and other vendors also publish builds of their own, each with its own support periods and paid support offers. Answer two questions about your own use, and the table marks the builds that fit:

In short: Temurin 25 fits nearly every case, Oracle JDK 25 fits organisations that work with Oracle’s JDK and keep its licence terms in view, and the jdk.java.net build of JDK 25 is ruled out for anything that needs updates, because it receives none.

The same program shows the difference between two buildsJDK build: One vendor's compiled JDK of a release, such as Eclipse Temurin 25.0.4.1 or Oracle JDK 25. Every build of a release runs the same programs; the licence, the update period and the platforms covered differ. of JDK 25 on one computer: Temurin 25.0.4.1, and the OpenJDK 25.0.2 build that Oracle published on jdk.java.net:

// Prints what this JDK build says about itself.
void main() {
    Runtime.Version version = Runtime.version();
    boolean lts = version.optional().map(text -> text.startsWith("LTS")).orElse(false);
    IO.println("version:        " + version);
    IO.println("feature/update: " + version.feature() + " / " + version.update());
    IO.println("marked LTS:     " + lts);
    IO.println("vendor:         " + System.getProperty("java.vendor"));
    IO.println("vendor build:   " + Objects.requireNonNullElse(System.getProperty("java.vendor.version"), "(none)"));
}

from session import run

# One program, two builds of JDK 25 from two vendors.
run("java Build.java")
run("java Build.java", jdk="25-jdk.java.net")

# JDK in use: openjdk version "25.0.4.1" LTS
$ java Build.java
version:        25.0.4.1+1-LTS
feature/update: 25 / 4
marked LTS:     true
vendor:         Eclipse Adoptium
vendor build:   Temurin-25.0.4.1+1
# JDK in use: openjdk version "25.0.2"
$ java Build.java
version:        25.0.2+10-69
feature/update: 25 / 2
marked LTS:     false
vendor:         Oracle Corporation
vendor build:   (none)

Both run Java 25, but the Temurin build is two updates ahead and is marked LTS in its version, which is how a vendor says that it supports the release for the long term. Oracle’s OpenJDK builds on jdk.java.net cover only the current feature release, so 25.0.2 received no further updates there once JDK 26 was out.

Installing takes one installer or one command

Use one of these routes, then check the installation as the next section shows:

• Windows. Run winget install EclipseAdoptium.Temurin.25.JDK in a terminal, or download the .msi installer from adoptium.net. The installer puts Temurin in C:\Program Files\Eclipse Adoptium\ and adds it to PATH by default; setting JAVA_HOME is an extra feature that you switch on in its Custom Setup screen. Switch it on.
• macOS. Download the .pkg installer from adoptium.net and open it. Temurin goes into /Library/Java/JavaVirtualMachines/temurin-<version>.jdk/, and the JDK’s own folder, the one JAVA_HOME names, is Contents/Home inside it.
• Linux. Add Adoptium’s package repository as its Linux page describes, then install the package temurin-25-jdk with your package manager: sudo apt install temurin-25-jdk on Debian and Ubuntu, sudo dnf install temurin-25-jdk on Fedora and Red Hat, sudo zypper install temurin-25-jdk on openSUSE or sudo apk add temurin-25-jdk on Alpine.
• Any system, one JDK per project. The version manager mise installs JDKs per project: in a project folder, mise use java@temurin-25 installs the newest Temurin 25 and records the choice in the project’s mise.toml. Name the exact build, mise use java@temurin-25.0.4+101.0.LTS, when everyone must run precisely the same one.

Installer screens and package names can change between releases; when a step looks different, follow the vendor’s installation page for your system. Whichever route you take, the steps after it are the same. Step through them, including the way back when a check reports another version:

The launcher and the compiler must both report 25

Open a new terminal (one opened before the install still has the old settings) and run the two checks, java -version for the launcher and javac -version for the compiler. Here they are with JDK 25 first on PATH, and then with JDK 21, which is what you would see if an older JDK came first:

from session import run

# The check after an install: the launcher and the compiler, first with JDK 25 on PATH, then with JDK 21.
run("""
java -version
javac -version
""")
run("""
java -version
javac -version
""", jdk="21")

# JDK in use: openjdk version "25.0.4.1" LTS
$ java -version
openjdk version "25.0.4.1" LTS
OpenJDK Runtime Environment Temurin-25.0.4.1+1 (build 25.0.4.1+1-LTS)
OpenJDK 64-Bit Server VM Temurin-25.0.4.1+1 (build 25.0.4.1+1-LTS, mixed mode, sharing)
$ javac -version
javac 25.0.4.1
# JDK in use: openjdk version "21.0.12.1" LTS
$ java -version
openjdk version "21.0.12.1" LTS
OpenJDK Runtime Environment Temurin-21.0.12.1+1 (build 21.0.12.1+1-LTS)
OpenJDK 64-Bit Server VM Temurin-21.0.12.1+1 (build 21.0.12.1+1-LTS, mixed mode, sharing)
$ javac -version
javac 21.0.12.1

Read the three lines of java -version from the top:

1. openjdk version "25.0.4.1" LTS: the version, and LTS because this build has long-term support. The real line also shows the build’s release date after the version, which these sessions leave out.
2. OpenJDK Runtime Environment Temurin-25.0.4.1+1: the vendor’s name for the build, here Temurin.
3. OpenJDK 64-Bit Server VM ... mixed mode, sharing: the JVM. Mixed mode is the interpreter with the JIT compiler from lesson 1, and sharing means it started from a class data sharing archive, a ready-made image of about 1,300 core library classes that shortens start-up.

javac -version prints one line. If either command reports something other than 25, or command not found, the java that your terminal finds is not the JDK you installed; the section on how each tool chooses a JDK, below, fixes that.

-version writes to standard error, –version to standard output

The two spellings print almost the same text to different places. The java documentation says that -version prints to the error stream and --version to the output stream, and that matters as soon as a script reads the version:

from session import run

# -version writes to standard error and --version to standard output; the last line of -version names the JVM's modes.
run("""
java -version 2>/dev/null
java --version 2>/dev/null
java -version 2>&1 | head -n 1
java -Xshare:off -version 2>&1 | tail -n 1
""")

# JDK in use: openjdk version "25.0.4.1" LTS
$ java -version 2>/dev/null
$ java --version 2>/dev/null
openjdk 25.0.4.1 LTS
OpenJDK Runtime Environment Temurin-25.0.4.1+1 (build 25.0.4.1+1-LTS)
OpenJDK 64-Bit Server VM Temurin-25.0.4.1+1 (build 25.0.4.1+1-LTS, mixed mode, sharing)
$ java -version 2>&1 | head -n 1
openjdk version "25.0.4.1" LTS
$ java -Xshare:off -version 2>&1 | tail -n 1
OpenJDK 64-Bit Server VM Temurin-25.0.4.1+1 (build 25.0.4.1+1-LTS, mixed mode)

With standard error thrown away (2>/dev/null), -version prints nothing at all, while --version still prints its three lines, starting openjdk 25.0.4.1 without the word “version”. A script that reads java -version must redirect standard error into the pipe with 2>&1, as the third command does. The last command switches class data sharing off, and the word sharing disappears from the JVM’s line.

A Java version is four numbers, a build number and a label

Since JDK 10, a Java version follows the scheme of JEP 322: up to four numbers, then a build number and an optional label. Temurin’s full version, 25.0.4.1+1-LTS, reads like this:

• 25 is the feature release; it goes up by one every six months.
• 0 is the interim number, reserved for releases between feature releases; under the current timetable it stays 0.
• 4 is the update: the fourth quarterly update of JDK 25.
• 1 is the patch: an extra release on top of update 4, for an urgent fix.
• +1 is the build number.
• -LTS is a label: the vendor supports this release for the long term.

Step through the same parts one at a time, then see how they read in the first build of JDK 27:

Zeros at the end are left out, so the first release of JDK 27 is simply 27, and Temurin’s first build of it is 27+35. The java.lang.Runtime.Version class reads these parts for a program: feature(), interim(), update(), patch() and build(), as Build.java does above.

The terminal, build tools and the IDE each choose a JDK

A computer can hold several JDKs at once, and each tool decides for itself which one to run:

• Your terminal runs the first java it finds while searching the folders of PATH, in order. In a macOS or Linux shell, command -v java prints which file that is; in the Windows Command Prompt, where java lists every match in order.
• Build tools look at JAVA_HOME first. Maven’s installation guide asks for either JAVA_HOME or java on PATH, and the Android documentation describes the same order for Gradle run from a terminal: JAVA_HOME if it is set, otherwise the java on PATH.
• Your IDE has a JDK setting of its own for each project, which matches neither of the other two unless you choose the same JDK there.

The JVM can report where its own JDK is installed. java.home is the folder that JAVA_HOME should name, the one that holds bin:

from session import run

# Which java is first on PATH, and where its JDK lives.
run("""
command -v java
java -XshowSettings:properties -version 2>&1 | grep -E "java\\.(home|vendor|version) "
""")

# JDK in use: openjdk version "25.0.4.1" LTS
$ command -v java
<JDK folder>/bin/java
$ java -XshowSettings:properties -version 2>&1 | grep -E "java\.(home|vendor|version) "
    java.home = <JDK folder>
    java.vendor = Eclipse Adoptium
    java.version = 25.0.4.1

The session writes the JDK’s own folder as <JDK folder>, because its real name differs from one computer to the next; on yours it is a real path, such as the Contents/Home folder of a macOS install. command -v java names the bin/java inside it, and java.home names the folder itself.

To set both variables yourself, for example after unpacking a JDK from an archive, point JAVA_HOME at the JDK’s folder and put its bin folder first on PATH. In a macOS or Linux shell, add export JAVA_HOME=/path/to/jdk-25 and export PATH="$JAVA_HOME/bin:$PATH" to your shell’s start-up file (~/.zshrc or ~/.bashrc). On Windows, open System Properties > Environment Variables, set JAVA_HOME to the JDK’s folder, and add %JAVA_HOME%\bin near the top of Path. Then open a new terminal and run the two checks again.

“release version 25 not supported” means an older javac ran

The most common symptom is a compiler that is older than the release a project asks for. Here the same command runs first with the javac of JDK 21 and then with the javac of JDK 25:

from session import run

# The same compile command with the javac of JDK 21, then with the javac of JDK 25.
run("javac --release 25 -d out Hello.java", jdk="21", expect_failure=["javac --release 25 -d out Hello.java"])
run("""
javac --release 25 -d out Hello.java
java -cp out Hello
""")

# JDK in use: openjdk version "21.0.12.1" LTS
$ javac --release 25 -d out Hello.java
error: release version 25 not supported
Usage: javac <options> <source files>
use --help for a list of possible options
[exit status 2]
# JDK in use: openjdk version "25.0.4.1" LTS
$ javac --release 25 -d out Hello.java
$ java -cp out Hello
Compiled for Java 25

error: release version 25 not supported means that the javac which ran does not know Java 25 at all. When an IDE or a build tool prints it while your terminal happily reports 25, that tool is running an older JDK: compare its JDK setting, or the JAVA_HOME it sees, with the output of java -XshowSettings:properties -version in your terminal. Step through such a case, with the messages of the session above:

A version manager pins the JDK per project

On a computer with several projects, a version manager keeps the choice inside each project. With mise, the command mise use java@temurin-25.0.4+101.0.LTS records that exact build in the project’s mise.toml, and mise then sets JAVA_HOME to it for commands started with mise exec, for its tasks, and in shells where mise is activated. Its documentation adds two cautions: tools that read JAVA_HOME once at start-up, such as an IDE, see a new version only after a restart, and a plain java@25 means the newest Temurin 25, because Temurin is mise’s default vendor for Java. Without a pin, plain java in a new terminal finds whichever JDK comes first on PATH, which may be an older JDK 21 that cannot run the compact source files of the next lesson.

Practise: the same feature release?

Write sameFeature, which receives the first line of java -version and the line of javac -version, and returns true when both name the same feature release. The four checks use lines recorded in this lesson’s sessions, without the release date. Run java SameFeature.java until every check passes.

// Exercise: do java and javac come from the same feature release?
// Write the body of sameFeature, then run: java SameFeature.java
boolean sameFeature(String javaLine, String javacLine) {
    // javaLine is the first line that java -version prints, javacLine the line that javac -version prints.
    return false;
}

void check(String javaLine, String javacLine, boolean expected) {
    boolean got = sameFeature(javaLine, javacLine);
    IO.println((got == expected ? "PASS" : "FAIL") + "  " + javaLine + "  |  " + javacLine + "  ->  " + got);
}

void main() {
    check("openjdk version \"25.0.4.1\" LTS", "javac 25.0.4.1", true);
    check("openjdk version \"21.0.12.1\" LTS", "javac 25.0.4.1", false);
    check("openjdk version \"25.0.2\"", "javac 25.0.4.1", true);
    check("openjdk version \"25.0.4.1\" LTS", "javac 21.0.12.1", false);
}

As given, sameFeature always returns false, so the two checks that expect true fail:

from session import run

# The exercise as given: sameFeature always answers false.
run("java SameFeature.java")

# JDK in use: openjdk version "25.0.4.1" LTS
$ java SameFeature.java
FAIL  openjdk version "25.0.4.1" LTS  |  javac 25.0.4.1  ->  false
PASS  openjdk version "21.0.12.1" LTS  |  javac 25.0.4.1  ->  false
FAIL  openjdk version "25.0.2"  |  javac 25.0.4.1  ->  false
PASS  openjdk version "25.0.4.1" LTS  |  javac 21.0.12.1  ->  false

First hint: the version in javaLine is the text between the two quote characters (indexOf('"') and lastIndexOf('"') find them), and in javacLine it is the text after the space. Runtime.Version.parse(...) turns either text into a version whose feature() you can compare.

Then practise the five ideas of the lesson, from choosing a build to the tools that each pick a JDK. The questions adapt to your answers, and every answer comes with its reason:

Interview questions

Fresher · What do the numbers in a Java version such as 25.0.4.1+1-LTS mean?

Since JDK 10, versions follow JEP 322. The first number is the feature release, 25, which goes up every six months. The second, interim, is reserved and stays 0 under the current timetable. The third, update, counts the quarterly bug-fix and security updates of that release: this is the fourth. The fourth number, patch, marks an extra release for an urgent fix on top of update 4. After + comes the build number, and a trailing -LTS says that the vendor supports the release for the long term. Zeros at the end are dropped, so the first JDK 27 release is simply 27. In code, Runtime.version() returns these parts through feature(), update() and the other accessors, which is safer than taking the version text apart by hand.

Key takeaways

• Builds of JDK 25 run the same programs but differ in licence and in how long updates continue: Temurin 25 is open source and updated until at least 2031, Oracle JDK 25 is at no cost until a year after JDK 29 and then under the OTN licence, and Oracle’s jdk.java.net builds stop at the next feature release.
• Every route, an installer, a package or mise, ends with the same two checks in a newly opened terminal.
• java -version and javac -version must both report 25, and -version writes to standard error, so a script reads it with 2>&1.
• A version such as 25.0.4.1+1-LTS is the feature, interim, update and patch numbers, then the build number and a label.
• The terminal uses the first java on PATH, build tools prefer JAVA_HOME and an IDE has its own setting, and release version 25 not supported means that the javac which ran is older than JDK 25.