Fedora 45 ships exactly one long-term-support JDK, OpenJDK 25. Java 21 and Java 17 are gone from the repositories, and java-latest-openjdk installs a JDK 27 build that still calls itself 27-ea. A project on 25 is one dnf command away. One on 21 or 17 needs a second repository, and you need to know that switching java does not switch javac.
This guide shows you how to install Java on Fedora, with OpenJDK 25 from the Fedora repositories, Eclipse Temurin 21 or 17 from the Adoptium repository, and both side by side with alternatives deciding the default. It also sets JAVA_HOME so Maven picks the right JDK and fixes the class version error that mixed JDKs produce. Everything was run on Fedora 45 in October 2026, and the JDK 25 install and the Adoptium repository check were repeated on Fedora 44, which carries the same two JDK packages.
Check which JDKs Fedora ships
Ask the repositories before you install anything, because the answer decides where each JDK comes from. Fedora 45 packages one LTS and the newest feature release, so this query is short:
dnf repoquery --qf "%{name} %{version}-%{release} %{repoid}\n" "java-*-openjdk" "java-*-openjdk-devel" "java-*-openjdk-headless" | sortFedora 45 answers with two JDKs and nothing older, so anything before 25 has to come from somewhere else.
java-25-openjdk 25.0.4.1.1-1.1.fc45 fedora
java-25-openjdk-devel 25.0.4.1.1-1.1.fc45 fedora
java-25-openjdk-headless 25.0.4.1.1-1.1.fc45 fedora
java-latest-openjdk 27.0.0.0.35-0.0.1.0.ea.fc45 fedora
java-latest-openjdk-devel 27.0.0.0.35-0.0.1.0.ea.fc45 fedora
java-latest-openjdk-headless 27.0.0.0.35-0.0.1.0.ea.fc45 fedoraFedora 44 lists the same two packages in its updates repository, so the steps below should apply to both releases. Its base repository still holds the older JDK 26 build of java-latest-openjdk, which is why a fully updated system matters before you compare versions. That leaves a simple map of where each Java version comes from:
| Java version | Source on Fedora 45 / 44 | Package |
|---|---|---|
| 25 (LTS) | Fedora repositories | java-25-openjdk-devel |
| 27 | Fedora repositories, labelled early access | java-latest-openjdk-devel |
| 21 (LTS) | Adoptium repository | temurin-21-jdk |
| 17 (LTS) | Adoptium repository | temurin-17-jdk |
| 11 and 8 | Adoptium repository | temurin-11-jdk, temurin-8-jdk |
For a new project, use 25: it is the current LTS, Fedora patches it, and it needs no extra repository. Reach for Temurin only when a build or a vendor certification names an older release, which is still common with Java 17 and 21 in enterprise code. We’d treat java-latest-openjdk as a way to try new language features, not as something to ship on.
Install OpenJDK 25 on Fedora
Install the JDK, which includes javac, from the Fedora repositories. The java-devel name resolves to the same package, so either spelling works:
sudo dnf install java-25-openjdk-develWatch the package count before you confirm. On a minimal Fedora 45 VM this command wanted 225 packages, far more than a compiler needs, because the full JDK pulls in fonts, X11 libraries and sound support through weak dependencies. We measured three ways to install it with dnf install --assumeno, which resolves the transaction without changing anything:
| Command | Packages | Download | Disk used |
|---|---|---|---|
dnf install java-25-openjdk-devel | 225 | 216 MiB | 803 MiB |
dnf install --setopt=install_weak_deps=False java-25-openjdk-devel | 30 | 69 MiB | 263 MiB |
dnf install java-25-openjdk-headless (runtime only) | 15 | 61 MiB | 246 MiB |
Turning weak dependencies off saves 540 MiB and still gives you a working compiler. We compiled and ran a class with that install, and it behaved like the full JDK minus the desktop extras. Pick the install by what the machine does:
- Desktop or IDE workstation: the default command
- Build server or CI runner: weak dependencies off
- Server that only runs JARs:
java-25-openjdk-headless
The desktop gets the full set because a Swing tool or an IDE needs those libraries anyway. For a build server, the lean command is:
sudo dnf install --setopt=install_weak_deps=False java-25-openjdk-develCheck both the runtime and the compiler, because a JRE-only install answers the first command and fails the second. A missing javac means only the headless or runtime package landed, so install the -devel package on top:
java -version
javac -versionBoth report the Red Hat build of 25, and the date in the first line is the upstream release date of that update.
openjdk version "25.0.4.1" 2026-08-18
OpenJDK Runtime Environment (Red_Hat-25.0.4.1.1-1) (build 25.0.4.1+1)
OpenJDK 64-Bit Server VM (Red_Hat-25.0.4.1.1-1) (build 25.0.4.1+1, mixed mode, sharing)
javac 25.0.4.1Try JDK 27 with java-latest-openjdk
Fedora’s rolling java-latest-openjdk package tracks the newest feature release, which is JDK 27 on Fedora 45. It installs next to 25 without touching your default, so it is safe to add on a machine that already builds with 25. Call it by its full path to see what you got:
sudo dnf install java-latest-openjdk-devel
/usr/lib/jvm/java-latest-openjdk/bin/java -versionThe version string is the thing to notice, because it is not what the package name suggests.
openjdk version "27-ea" 2026-09-15
OpenJDK Runtime Environment (Red_Hat-27.0.0.0.35-1) (build 27-ea+35)
OpenJDK 64-Bit Server VM (Red_Hat-27.0.0.0.35-1) (build 27-ea+35, mixed mode, sharing)Upstream JDK 27 reached general availability on September 15, 2026, but this Fedora build still carries the ea tag in both the RPM release and java -version. Anything that parses java -version sees an early-access build. Fedora also registers it in alternatives with priority 1 against 25000421 for JDK 25, so it never becomes the default on its own. Use it to try JDK 27 features. If you need a JDK 27 that reports itself as a release build, Temurin publishes temurin-27-jdk in the same repository as 21 and 17.
Install Java 21 or 17 from Eclipse Temurin
Adoptium publishes Temurin RPMs per Fedora release under packages.adoptium.net. If Adoptium has not published a tree for your release yet, which was the case for Fedora 45 when we tested, the URL returns 404 and dnf refuses the repository. The commands below check for your release’s tree first and fall back to the previous release. Temurin’s RPMs are built against common system libraries rather than one Fedora release, and the Fedora 44 packages installed and ran on Fedora 45 in our test:
REL=$(rpm -E %fedora)
curl -sfI "https://packages.adoptium.net/artifactory/rpm/fedora/${REL}/x86_64/repodata/repomd.xml" >/dev/null || REL=$((REL - 1))
echo "Using the Adoptium Fedora ${REL} tree"
printf "%s\n" "[adoptium]" "name=Eclipse Temurin" "baseurl=https://packages.adoptium.net/artifactory/rpm/fedora/${REL}/\$basearch" "enabled=1" "gpgcheck=1" "gpgkey=https://packages.adoptium.net/artifactory/api/gpg/key/public" | sudo tee /etc/yum.repos.d/adoptium.repoRead the echoed release before going on. The check can’t tell a 404 from a network failure, so if your release has a tree and the line still names the previous one, fix the connection and rerun it. On Fedora 45 the check picked the Fedora 44 tree and wrote this repository file:
Using the Adoptium Fedora 44 tree
[adoptium]
name=Eclipse Temurin
baseurl=https://packages.adoptium.net/artifactory/rpm/fedora/44/$basearch
enabled=1
gpgcheck=1
gpgkey=https://packages.adoptium.net/artifactory/api/gpg/key/publicThe file keeps pointing at the tree it found, so once Adoptium publishes Fedora 45 you can rerun the block to move to it. Nothing breaks if you don’t. The repository carries every Temurin LTS plus recent feature releases:
dnf repoquery --qf "%{name} %{version}\n" "temurin-*-jdk" | sort -V | awk "{print \$1}" | uniqEach major version is its own package, so 21 and 17 can be installed together without a conflict.
temurin-8-jdk
temurin-11-jdk
temurin-17-jdk
temurin-21-jdk
temurin-25-jdk
temurin-26-jdk
temurin-27-jdkInstall Temurin 21. For Java 17, install temurin-17-jdk and replace 21 with 17 in every path that follows. We only installed 21, but the 17 package in Adoptium’s repository uses the same layout, /usr/lib/jvm/java-17-temurin-jdk with a temurin-17-jdk symlink:
sudo dnf install temurin-21-jdkdnf asks you to trust the Adoptium signing key on the first install, because the repository file enables gpgcheck. That prompt is the only point where you vouch for a third-party repository, so compare the fingerprint it prints with this one before you answer yes:
Importing OpenPGP key 0x65F8F04B:
Fingerprint: 3B04D753C9050D9A5D343F39843C48A565F8F04BThe JDK itself is 344 MiB installed. It also depends on Fedora’s X11, ALSA and fontconfig libraries, which were already present on our VM from the full JDK 25 install, so dnf only added dejavu-sans-fonts next to it. On a minimal server expect a longer list. Run it by its full path, since installing it does not change your default:
/usr/lib/jvm/temurin-21-jdk/bin/java -versionThe Temurin build string and the LTS tag confirm which JDK answered. Fedora’s own builds say Red_Hat in the same place, so this line is the quickest way to tell them apart.
openjdk version "21.0.12.1" 2026-08-18 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)/usr/lib/jvm/temurin-21-jdk is a symlink to the real directory, /usr/lib/jvm/java-21-temurin-jdk. Either path works in scripts, but alternatives only knows the second one, which matters in the next step.
Switch the default Java version
Fedora picks the default java through alternatives, and in automatic mode the highest priority wins. Fedora’s JDK 25 registers with a priority in the millions, so it stays the default even after you add Temurin:
alternatives --display java | grep -E "status|points|priority"All three JDKs are registered, and JDK 25 holds the link because its priority is the highest.
To make Temurin 21 the default, set the alternative by the path it was registered under. On Fedora, java and javac are separate alternatives, and setting only java left us with a 21 runtime and a 25 compiler:
sudo alternatives --set java /usr/lib/jvm/java-21-temurin-jdk/bin/java
java -version 2>&1 | head -1
javac -versionThe two commands now disagree by four major versions, which is exactly the setup that produces the class version error at the end of this guide.
openjdk version "21.0.12.1" 2026-08-18 LTS
javac 25.0.4.1Set the compiler as well, so both point at the same JDK. Fedora does not link the two, so you have to set each one yourself:
sudo alternatives --set javac /usr/lib/jvm/java-21-temurin-jdk/bin/javac
javac -versionIt reports javac 21.0.12.1. To hand the choice back to Fedora’s priorities, put both alternatives in automatic mode again, which returns them to JDK 25:
sudo alternatives --auto java
sudo alternatives --auto javacWe’d leave the system default on Fedora’s JDK 25 and pick older JDKs per project with JAVA_HOME, covered next. The system default is shared by every user and every service on the machine, while a per-project setting can’t break somebody else’s build.
Set JAVA_HOME on Fedora
Fedora does not set JAVA_HOME, and the usual shortcut, /usr/lib/jvm/java, only works while Fedora’s javac is the default. That path is a java_sdk link that follows the javac alternative, and Temurin’s packages don’t provide it. With only java switched to Temurin, /usr/lib/jvm/java still resolved to JDK 25. Once we set javac to Temurin too, the link disappeared altogether, and alternatives --auto javac brought it back on JDK 25. So point JAVA_HOME at a real JDK directory instead. Install Maven first so you have something to test with:
sudo dnf install maven
mvn -v 2>&1 | grep -E "Apache Maven|Java version|runtime"Fedora’s Maven package depends on maven-openjdk25, so with nothing else set it builds with JDK 25:
Apache Maven 3.9.11 (Red Hat 3.9.11-16)
Java version: 25.0.4.1, vendor: Red Hat, Inc., runtime: /usr/lib/jvm/java-25-openjdkFor one project, or one build, set JAVA_HOME on the command itself. It applies to that command only, so it can’t leak into anything else you run:
JAVA_HOME=/usr/lib/jvm/temurin-21-jdk mvn -v 2>&1 | grep -E "Java version|runtime"Maven switches to Temurin for that run:
Java version: 21.0.12.1, vendor: Eclipse Adoptium, runtime: /usr/lib/jvm/java-21-temurin-jdkUse the same prefix for real builds (JAVA_HOME=/usr/lib/jvm/temurin-21-jdk mvn package), or put it in the project’s build script. If every project you build as this user needs 21, make it your user default instead. Run these lines once, since running them again appends duplicates, and remember they change every new shell you open:
echo "export JAVA_HOME=/usr/lib/jvm/temurin-21-jdk" >> ~/.bashrc
echo "export PATH=\$JAVA_HOME/bin:\$PATH" >> ~/.bashrc
source ~/.bashrcPutting $JAVA_HOME/bin first in PATH makes the plain java and javac commands agree with Maven. Check all four:
echo $JAVA_HOME
java -version 2>&1 | head -1
javac -version
mvn -v 2>&1 | grep "Java version"All four agree on Temurin 21. If one of them still shows 25, you are in a shell that started before the export, so open a new terminal or source the file again.
/usr/lib/jvm/temurin-21-jdk
openjdk version "21.0.12.1" 2026-08-18 LTS
javac 21.0.12.1
Java version: 21.0.12.1, vendor: Eclipse Adoptium, runtime: /usr/lib/jvm/java-21-temurin-jdkTo undo it, delete the two export lines from ~/.bashrc and open a new terminal. The setting only reaches programs started from your shell. A service started by systemd, such as Tomcat, never reads ~/.bashrc and needs JAVA_HOME in its own configuration, which our Tomcat guide covers. On RHEL or Rocky Linux the same idea applies, and the JAVA_HOME guide for RHEL and Rocky covers the system-wide variant. If you need a newer Maven than Fedora packages, the Maven install guide covers the upstream tarball.
Fix UnsupportedClassVersionError
Mix JDKs on one machine and sooner or later you’ll compile with one and run with another. We reproduced it with a small class, so create a scratch directory and open the source file. If vim isn’t found, install vim-enhanced or use nano, Fedora’s default editor:
mkdir -p ~/hello
vim ~/hello/Hello.javaThe class prints the version of whichever runtime executes it, which makes a mismatch obvious:
public class Hello {
public static void main(String[] args) {
System.out.println("Hello from Java " + Runtime.version());
}
}Compile it with JDK 25’s javac and run it on Temurin 21. Both are called by their full paths, so the result doesn’t depend on the alternatives or JAVA_HOME changes above:
cd ~/hello
/usr/lib/jvm/java-25-openjdk/bin/javac Hello.java
/usr/lib/jvm/temurin-21-jdk/bin/java HelloThe JVM refuses to load the class, and you get the error before a single line of your code runs.
Error: LinkageError occurred while loading main class Hello
java.lang.UnsupportedClassVersionError: Hello has been compiled by a more recent version of the Java Runtime (class file version 69.0), this version of the Java Runtime only recognizes class file versions up to 65.0The two numbers tell you which JDKs are involved. Class file version 69 is Java 25 and 65 is Java 21, because the major version is always the Java release plus 44. The class was built for a newer runtime than the one trying to run it, so you compile for the oldest runtime you deploy to. javac --release 21 does that from JDK 25. It also checks your code against the Java 21 API, which a bare target flag would not:
/usr/lib/jvm/java-25-openjdk/bin/javac --release 21 Hello.java
/usr/lib/jvm/temurin-21-jdk/bin/java HelloThe same class now runs on 21:
Every build tool has its own name for that target release, and it belongs in the project rather than in your shell:
- javac:
--release 21 - Maven: the
maven.compiler.releaseproperty in the POM - Gradle:
options.releaseon theJavaCompiletask
When you see this error from a JAR you did not build, the fix runs the other way. Install the runtime the error names. A class file version of 69 needs Java 25 or newer, which on Fedora is the java-25-openjdk-headless package. If you only want to run a single source file, skip javac entirely: /usr/lib/jvm/temurin-21-jdk/bin/java Hello.java compiles in memory with the JDK that runs it, so the versions can’t drift apart. For the rest of a fresh workstation, our Fedora 45 post-install checklist picks up from here.
