Install Oracle Java on CentOS, RHEL & Fedora

In this article I walk you through my preferred method of installing Oracle Java on CentOS Linux. The install is quick and easy and gives you a flexible way of updating Java as new versions are released. These steps can be applied to Red Hat Enterprise Linux (RHEL) and Fedora as well. In a nut shell, we will:

  • Fetch the latest JDK and extract it to the /opt directory.
  • Create a symbolic link so that /opt/java points to the specific version of Java we installed.
  • Update our environment so that JAVA_HOME points to /opt/java.
  • Handle any gotchas.
  • Test our installation.

Note that this article is primarily targeted towards servers where Oracle Java is the only Java.  We don’t cover utilities such as “alternatives” that help manage multi-binary configurations. In my day to day work and on my personal servers, the steps outlined in this article are my go to method. If you are installing Java on a desktop machine, be prepared to do a bit of follow up work to make sure Oracle Java is available when you need it. See the “gotchas” section for more info.

Super Express Install

If you are in a real hurry and just want Oracle Java installed with a minimal amount of hassle, I have an installer available on GitHub that will literally have you up and running in a matter of seconds.  Follow these instructions to take advantage of that method.  Once complete, the script provides steps to verify the installation.  I always keep this script updated to install the latest 64 bit JDK release.

Step 1 – Get the JDK

Assuming you want the latest version of the JDK, simply head to Oracle’s download page. Once there, click the JDK download link. This takes you to another page where you will find the various platform-dependent release links.

On the resulting page, check the “Accept License Agreement” check-box, and then click the Linux tar.gz download link matching your architecture, Linux x86 for 32 bit and Linux x64 for 64 bit.  These days I pretty much always get the 64 bit version.   As I write this 8u77 is the latest so I would click jdk-8u77-linux-x64.tar.gz.  For my method, its important to fetch the tar.gz version, not the RPM.  Once you have the file, upload it to your target server.

Quick Tip to Download Directly From a Remote Server

Since you are required to check the “Accept License Agreement” box, there isn’t an easy way to copy the download link and paste it as a param to wget to fetch the file directly from your remote server. However, if you pass a header cookie into wget indicating you accept the agreement, it is possible. Let’s say the download link is (note you must accept the agreement in order for the download link to be visible in your browser). You could then download the file directly to your server with this rather lengthy wget command. This is how my “super express install” method gets the job done.

Now that we have the file, let’s extract it to the /opt directory:

Okay, we are now ready for the next step.

Step 2 – Sym Link /opt/java to the Versioned JDK

This next step is the most significant as it allows us to standardize our Java settings regardless of the version of the JDK we are using. As you are probably aware, Java updates are released regularly. Many Java applications such as Tomcat, Maven, GlassFish, WildFly, Derby, etc. depend on the JAVA_HOME environment variable being set properly. If we were to set that to something like /opt/jdk1.8.0_77, the next time we updated our JDK, we’d have to update JAVA_HOME. If, on the other hand, we set JAVA_HOME to /opt/java and then use a symbolic link to point /opt/java to /opt/jdk1.8.0_77, the next time a new JDK is released, we simply need to install it and update our symbolic link. We basically always keep /opt/java pointing to our “active” Java and leave JAVA_HOME alone. This is how we go about it at the command line:

At this point, if you were to type /opt/java/bin/java -version, you’d be able to verify version 1.8.0_77.

Step 3 – Set JAVA_HOME Environment Variable

Now that we have Java installed and have our /opt/java symbolic link in place, we simply need to set the JAVA_HOME environment variable and update our path. I typically do this by creating a file in /etc/profile.d/. I call it “” with the following contents:

Okay, almost there! To make the environment settings take affect, you can either log out and log back in or source the file:

Step 4 – Handle any Gotchas

At this point you should be good to go. If you happen to be installing on a desktop system that has a version of OpenJDK installed (to support Libre Office, for example), you’ll want to make sure that when you type java or javac, you are getting the Oracle version of Java and not OpenJDK. You should do this on a server too, just to be sure. I typically type “which java” and “which javac” and verify that the answers returned are “/opt/java/bin/java” and “/opt/java/bin/javac”. Basically, you want to make sure you are not getting something like “/usr/bin/java” or “/bin/java”. If you do get back something else, you’ll want verify your path with “echo $PATH”. As you can see in step three, we put $JAVA_HOME/bin as the first entry in our path. Ninety-nine times out of a hundred, that will do the trick. If not, you may want to consider either uninstalling OpenJDK (on a server, I have yet to find a need for it) or going ahead and looking into a solution like alternatives. Alternatives is a command you can use to set the “active” java on your system when multiple java binaries are installed. If you go that route, it somewhat defeats the purpose of this article but I thought I would mention it anyway. To make /opt/java/bin/java the active java with alternatives, something like this should do the trick. But as I mentioned, you normally shouldn’t need to do this.

Step 5 – Test the Installation

Okay, that pretty much wraps it up. Take a break, pat yourself on the back and think of all the wonderful things you are going to do with Java. As a final verification, you can run a few commands to make sure that Java is ready to go and things are where we expect them. Below are sample commands with expected output.

That concludes this blog post. Thank you very much for taking the time to read it. I hope you found it helpful. One thing to note is that this installation approach can be used when installing other Java applications as well. With Maven, for example, my M2_HOME is always set to /opt/maven which is a symbolic link pointing to a version specific Maven (3.3.3 for example). Same with Tomcat, WildFly and many others. The idea is to keep everything in /opt and use generic symbolic links pointing to version specific directories. The real power is realized when upgrading as you only have to change a single sym link and everything else automatically picks up the change. Happy coding!