How to find your Java Home when running multiple versions

When you install Java, it's part of the installer's job to tell your system where to find the right language when it's needed. That's why you're able to run Java applications—in fact, you may sometimes run Java applications without ever realizing what language they've been written in.

Put simply, it just works, just as when you install Python to run a Python application, C to run an application written in C, and so on.

But what happens when you install more than one version of Java on your system? In that case, you'll have to take on the extra responsibility of understanding where each version's JAVA_HOME is located.

The easiest way to solve this issue is to use SDKMan. However, if you don't have SDKMan available, you need to do it manually.

Why you might want multiple versions of Java

There are a few reasons you might want more than one version of Java on your computer.

• Programming languages progress at one rate, while an application might develop at a different rate. It's possible for Java (the language) to increment its version number while your favorite application sticks with an older version. If you have two must-have applications, each of which uses a different version of Java, you may want to install both.

• Developers work on many different projects, some of which might use an old long-term support (LTS) version of Java while another uses the latest version.

• You might be on a system for which you don't have permission to install Java at the systemwide level. You can, instead, run Java out of your home directory, but that sometimes means you have to point applications to that nonstandard install location.

The JAVA_HOME variable

It's perfectly acceptable to have more than one version of Java installed, but applications may not know where to find the version it needs.

Normally, an application just uses whatever you have set as your default Java runtime. This is something you may not have set yourself. Depending on what Linux distribution you run and what method you've used to install Java, your system default could be the first version of Java you installed or the most recent one.

Regardless of what your default is, if you try to launch an application and then receive an error about the version of Java you're using, even though you know you've got the right version installed somewhere on your system, you can manually override the setting.

Applications can derive the location of Java from your current session's environment variables.

First, take a look at what, if anything, JAVA_HOME is set to currently:

$ echo $JAVA_HOME

If there's output, then your computer is maintaining a JAVA_HOME variable. If there's no output, then your computer doesn't have that variable set. That doesn't necessarily mean your computer has no Java home, it just means that nothing's bothered to set it yet.

Find the right version

Before you can set JAVA_HOME, you need to know which Java you want to use. Which Java you need to use depends on the application you're trying to run. If an application requires Java 8 to run, you need to point it to the bin directory containing Java 8. If an application requires Java 17 to run, you need to point it to the bin directory containing Java 17.

You can find your current default Java version with the -version option. Launch a terminal and type this command (omit the $ command prompt):

$ java -version

Find the right location from a package manager

Now you need to know where the version of Java you want to use is located.

If you installed Java through a package manager, you can query your package manager for a file list. This tells you what and where files were installed with that package.

For example, on Fedora, CentOS, or Mageia, you can list all installed packages and grep to see just packages containing the string java:

$ dnf list installed | grep java

For even cleaner output, use awk:

$ dnf list installed | awk --field-separator=' ' '/java/{print $1;}'
java-1.8.0-openjdk.x86_64
java-1.8.0-openjdk-devel.x86_64
java-1.8.0-openjdk-headless.x86_64
java-11-openjdk.x86_64
java-11-openjdk-devel.x86_64
java-11-openjdk-headless.x86_64
java-11-openjdk-src.x86_64
javapackages-filesystem.noarch
javapackages-tools.noarch
tzdata-java.noarch

Assume you need information on Java 8 (version 1.8).
You can see each file in the Java 8 packages using the rpm command:

$ rpm --query --all --list \
java-1.8.0-openjdk* | grep bin/java$
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.322.b06-2.el8_5.x86_64/jre/bin/java
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.322.b06-2.el8_5.x86_64/bin/java

You may get more than one result, but look at the file paths carefully. Generally, you just want the Java executable in the primary bin directory of its Java distribution.

In this example, the path to Java 8 is:

 /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.322.b06-2.el8_5.x86_64/bin

If you use a different package manager, the commands are different, but the goal remains the same. Consult your package manager's documentation for details.

Find the right location from a manual install

If you've manually installed Java from a .tar archive ("tarball"), your package manager has no record of it. Hopefully, howerer, you know where you put it, so finding the path to its JAVA_HOME is as simple as listing the absolute path to its bin directory.

Here's how I confirm that the directory I think ought to exist does in fact exist:

$ file /opt/jdk-1.8.0/bin

Set JAVA_HOME temporarily

Now you know the location of your desired JAVA_HOME.

To set a JAVA_HOME variable temporarily, you can precede the command you want to run with your variable setting. For instance, suppose you're on a system with both Java 8 and Java 11 installed on it. Java 8 was installed originally, but you downloaded Java 11 because a cool new application you want to try requires it.

Evironment variables placed before the command you're running get inherited by the command:

$ JAVA_HOME=/opt/jdk-1.8.0/bin coolNewApp

Set JAVA_HOME permanently with the alternatives command

To set a new default Java version permanently, use the alternatives command. The alternatives command looks at applications installed on your Linux system and lets you choose which version to use. Some distributions, such as Slackware, don't provide an alternatives command, so you must use the local install method instead.

On Fedora, CentOS, Mageia, and similar distributions, the command is alternatives.

On Debian and Ubuntu and similar, the command is update-alternatives.

To get a list of available versions of an application currently installed on your Fedora system:

$ alternatives --list

On Debian, you must specify the application you want alternatives for:

$ update-alternatives --list java

To choose which version you want to make the system default on Fedora and similar systems:

$ sudo alternatives --config java

On Debian-based systems:

$ sudo updates-alternatives --config java

You can change the default Java version as needed, based on which application you want to run.

Choose your Java

Usually, you don't have to worry about applications getting confused when using Java, but it's a benefit of Java that it allows you to have different versions installed at once. Thanks to that feature, you can run even old software that hasn't been updated to the latest version of Java, while still running the latest Java apps.

However, with that flexibility comes the responsibility of understanding how to guide applications to the correct version. Now you know how.

If this method seems like a lot of work, consider using SDKMan instead.