4 Ways to Install Java on Linux

Before Installing Java: JDK, JRE, and Version Choices

The first decision is whether you need a Java Development Kit or only a runtime environment.

• JDK: Includes the Java runtime, compiler, debugger, documentation tools, and other utilities needed to build Java applications.
• JRE: Provides what is necessary to run Java applications but does not include development tools such as javac.

For most users, installing a JDK is the sensible choice. It can run Java programs and gives you the compiler if you need it later. Separate JRE packages still exist in some Linux repositories, but modern Java installations increasingly center on complete JDK packages or application-specific runtime images.

Which Java version should you install?

Production systems usually favor a Long-Term Support release. As of 2026, Java 25 is the latest LTS release, while Java 21 remains widely deployed and supported. Java 26 is a newer feature release, but it has a shorter support window.

Before choosing, check the requirements of your application, build system, or server. A project that explicitly requires Java 17 may not appreciate being surprised with Java 26, even if the newer version has a shinier number.

Confirm your Linux distribution and processor architecture with:

An output of x86_64 normally requires an x64 build. Systems reporting aarch64 or arm64 need an ARM64 build.

Method 1: Install OpenJDK with the Linux Package Manager

The distribution package manager is the best installation method for most Linux users. It resolves dependencies, integrates Java with the operating system, and delivers security updates through normal system upgrades.

Ubuntu, Debian, and related distributions

Install the default development kit supplied by your distribution:

If you need a particular version and it is available in your enabled repositories, specify it directly:

Package availability depends on the Linux release. Use the following command to see what your system offers:

Fedora and Red Hat-based distributions

Fedora, Red Hat Enterprise Linux, Rocky Linux, and similar systems use RPM packages. Search first because supported versions differ among releases:

For example, the following installs the Java 21 JDK and development tools when that package is available:

A package ending in -devel generally includes the compiler and related development utilities. A headless runtime package is smaller and useful for servers that do not need graphical libraries.

Arch Linux

Arch users can install the repository’s current OpenJDK package with:

Version-specific packages may also be available. Search before installing:

openSUSE

On openSUSE, search for an available build and install the selected package with Zypper:

Why choose this method?

Package-manager installation is easy to maintain and difficult to accidentally misconfigure. Its main limitation is version availability. Stable Linux releases may intentionally provide an older LTS version rather than the newest Java release. That restraint is excellent for servers and mildly irritating for developers who want to test a feature announced five minutes ago.

Method 2: Install Java from a Vendor Repository

A third-party vendor repository combines package-manager convenience with access to a specific OpenJDK distribution. Popular choices include Eclipse Temurin, Amazon Corretto, Oracle JDK, Azul Zulu, and the Red Hat build of OpenJDK.

This method is helpful when your Linux repository lacks the required Java version or when an organization standardizes on one vendor’s binaries and support policy.

Example: Install Eclipse Temurin on Ubuntu or Debian

First, install the tools required to configure the repository:

Import the Eclipse Adoptium signing key:

Add the repository using the distribution codename:

Update the package index and install the desired Temurin JDK:

On Linux Mint, the applicable Ubuntu codename may be stored as UBUNTU_CODENAME rather than VERSION_CODENAME.

Repository safety and maintenance

Only add repositories documented by the JDK vendor. Verify the domain, signing-key instructions, supported Linux versions, license terms, and update policy. Avoid copying an anonymous repository configuration from an abandoned forum post whose final comment says, “Never mind, fixed it.”

Vendor packages normally receive updates through apt upgrade, dnf upgrade, or the equivalent system command. However, you are trusting an additional software source, so keep the repository definition and signing key under administrative review.

Method 3: Install a JDK Manually from a Tar.gz Archive

A manual archive installation gives you precise control over the JDK vendor, version, location, and update schedule. It also works when you do not have an appropriate package repository.

The examples below use placeholder filenames because update numbers and archive names change. Download the correct Linux archive from a trusted provider such as OpenJDK, Oracle, Eclipse Adoptium, or Amazon Corretto.

Step 1: Verify the download

Compare the archive’s checksum with the value published by the provider:

A checksum does not make an untrusted website trustworthy, but it can confirm that the downloaded file matches the vendor’s published artifact.

Step 2: Extract the JDK

A conventional system-wide location for manually managed software is /opt:

Suppose the extracted directory is /opt/jdk/jdk-25.0.1. Create a stable symbolic link so future upgrades do not require rewriting every environment variable:

Step 3: Configure JAVA_HOME and PATH

Add the following lines to ~/.bashrc for Bash or ~/.zshrc for Zsh:

Reload the shell configuration:

For a system-wide configuration, an administrator can place equivalent exports in a carefully managed file under /etc/profile.d/.

Step 4: Optionally register Java with alternatives

On Debian-based systems, a manual installation can be registered with the alternatives framework:

The disadvantage of a manual installation is equally manual maintenance. Your operating system will not automatically patch that archive. You must track security releases, download replacements, verify them, update the symbolic link, and retire old versions yourself.

Method 4: Install and Manage Java with SDKMAN!

SDKMAN! is particularly useful for developers who regularly switch among Java versions or vendors. It installs JDKs inside the user’s home directory, so it does not replace the system Java installation for every account.

Install SDKMAN!

Ensure that Bash or Zsh, curl, zip, and unzip are installed. Then run the official installer:

Piping an internet download directly into a shell is convenient but powerful. In security-sensitive environments, download and inspect the script before executing it.

Open a new terminal or initialize SDKMAN! in the current shell:

Install a Java version

List available JDK distributions and identifiers:

Install the current stable default offered by SDKMAN!:

To install a particular build, copy its exact identifier from sdk list java:

Switch between installed versions

Use one version in the current terminal:

Set a version as the default for future shells:

Check the active SDKMAN-managed version with:

SDKMAN! can also create a project-level .sdkmanrc file:

This makes it easier for team members to use the JDK expected by a project. SDKMAN! is excellent for interactive development, although a system package or pinned container image may be more predictable for production servers and automated deployments.

Verify That Java Is Installed Correctly

Regardless of the installation method, verify both the runtime and compiler:

The first two commands should report compatible versions. If java works but javac does not, you probably installed only a runtime package.

Compile a small Java program

Create a file named HelloLinux.java:

Compile and run it:

If the message appears, the compiler, runtime, classpath behavior, and command search path are functioning.

Managing Multiple Java Versions on Linux

It is common to keep Java 17 for an older application, Java 21 for production, and a newer release for testing. The challenge is not installing them; it is knowing which one your shell, service, IDE, and build tool are actually using.

On Ubuntu or Debian, select the system default runtime and compiler separately:

Fedora and Red Hat-based systems provide a similar command:

Arch Linux provides archlinux-java for selecting installed Java environments:

Remember that JAVA_HOME can disagree with the java found through PATH. Maven, Gradle, application servers, IDEs, and systemd services may also have their own Java configuration. Always inspect the environment from the same account and execution context that launches the application.

Common Java Installation Problems

“java: command not found”

The JDK may not be installed, or its bin directory may be missing from PATH. Run which java, inspect your shell startup file, and open a new terminal after changing environment variables.

JAVA_HOME points to the wrong directory

JAVA_HOME must reference the JDK root, not its bin directory and not the java executable. A correct value looks like /usr/lib/jvm/java-21-openjdk-amd64 or /opt/jdk/current.

The installed Java version is not the active version

Another JDK may appear earlier in PATH. Check which java, resolve the symbolic link, and review the alternatives configuration or SDKMAN! selection.

The package cannot be found

Your Linux release may not provide that Java version, or the package index may be outdated. Update repository metadata, search available package names, or use a supported vendor repository, SDKMAN!, or manual archive.

An application rejects a newer JDK

Java is strongly backward-compatible, but frameworks, plugins, bytecode tools, and application servers can impose exact version ranges. Install the supported JDK alongside the newer one and configure the application explicitly instead of changing the entire system unnecessarily.

Practical Experiences and Lessons from Installing Java on Linux

The easiest Java installation is often the one that matches how the machine will be maintained. On a personal Ubuntu workstation, default-jdk is usually painless. Updates arrive with the rest of the operating system, commands appear in standard locations, and IDEs tend to discover the JDK automatically. For someone learning Java or running a single application, that simplicity is worth more than having the newest release on launch day.

A different pattern emerges on development machines supporting several projects. One project may still compile for Java 17, another may require Java 21, and an experimental branch may test Java 25 or 26. Repeatedly changing the system-wide alternative becomes tedious and can affect unrelated software. SDKMAN! works well here because version switching is user-scoped. A project-level .sdkmanrc also documents the required JDK in a place developers are likely to notice.

One recurring source of confusion is assuming that the version printed by an interactive terminal is the version used everywhere. A developer may run java --version and see Java 25, while Maven uses another JAVA_HOME, the IDE uses its bundled runtime, and a systemd service launches Java 21 from an absolute path. Nothing is technically broken; four configurations are simply telling four different truths. Checking the executable path in the application’s actual execution context prevents hours of dramatic but unproductive staring.

Manual archive installations are valuable when a precise build must be pinned, especially on isolated systems or in testing environments. The symbolic-link patterninstalling versioned directories under /opt/jdk and pointing /opt/jdk/current to the active onemakes upgrades much cleaner. If a new update causes trouble, changing one link can restore the previous build. The important operational lesson is to document ownership of updates. A manually installed JDK will not patch itself merely because everyone assumed someone else was watching it.

Vendor repositories offer a comfortable middle ground. They preserve familiar package-manager behavior while providing a consistent JDK distribution across multiple Linux systems. This can reduce “works on my machine” differences between developer laptops and servers. The tradeoff is another repository, signing key, and support policy to manage. Organizations should record why the repository exists and who reviews it; mystery repositories age about as gracefully as mystery leftovers in an office refrigerator.

Architecture mismatches are another avoidable problem. An x64 archive cannot become an ARM64 JDK through positive thinking. Running uname -m before downloading saves time on cloud instances, Raspberry Pi systems, and ARM-based developer machines. The same care applies to Alpine Linux, where musl-based builds may be required instead of archives intended for glibc-based distributions.

Finally, verification should go beyond java --version. Checking javac, JAVA_HOME, the resolved executable path, and a tiny compiled program reveals different classes of mistakes. For production services, verify the runtime from the service account after restarting the service. For build pipelines, print the Java version near the beginning of each job. A few seconds of visible diagnostics can turn a mysterious build failure into a very ordinary version mismatchwhich is exactly how administrators prefer their mysteries.

Conclusion

There is no single best way to install Java on Linux for every situation. The distribution package manager is the safest default for most users. A vendor repository provides packaged updates from a chosen OpenJDK provider. A manual archive offers maximum control, while SDKMAN! is ideal for developers juggling multiple JDK versions.

Whichever method you choose, install a version supported by your application, verify both java and javac, keep JAVA_HOME consistent, and establish a clear update process. Java installation becomes much less mysterious once every tool agrees on which Java it is actually using.