Java Runtime Environment (JRE) on Linux/Unix

by (Thomas Hedden)

This article explains how to check whether the Java Runtime Environment (JRE) is installed on a Linux/Unix system, and if it is not installed, how to get it, install it, and configure it. This article will not cover the javac compiler, nor will it cover any operating systems other than Linux/Unix.

The following discussion is broken down into eight steps:

1. Checking whether the JRE is Installed
2. Checking the PATH Variable for the JRE
3. Finding the PATH Statement
4. Creating a Symbolic Link to the JRE
5. Adding the JRE to the PATH Statement in Login Files
6. Editing the PATH Statement in Login Files
7. Getting and Installing Java
8. Configuring the Java Plugin

Checking whether the JRE is Installed

There are several possible ways to check whether the Java Runtine Environment is installed on a Linux/Unix computer, depending on how the JRE was installed (if it actually was installed, that is) and what other programs are available to find installed programs. One of the easiest ways is to use the program called "locate".

Checking whether the JRE is Installed Using the "locate" Program

To check whether you have the "locate" program, first open an interactive shell (terminal window or console or X-term, etc.), and type:

$ which locate

If the "which" program responds with something like "/usr/bin/locate", then the "locate" program is installed. (If the "locate" program is not installed, then skip ahead and try using the "rpm" program: See below.) If the "locate" program is installed, then type:

$ locate 'bin/java'

If the "locate" program responds with something like "/usr/java/jre1.5.0_06/bin/java", then the JRE is almost certainly installed on your system, and all that remains is to check whether it is present in your PATH variable (see below). If the "locate" program does not give any response at all, then the JRE is almost certainly not installed on your system, although there are also other ways to check this (see below).

To determine whether you have found the actual location of the JRE or a symbolic link to it, type the "ls -l" command for every location that you found that you think might be where the JRE is located:

$ ls -l /usr/bin/java
lrwxrwxrwx 1 root root 22 2007-04-10 10:50 /usr/bin/java -> /etc/alternatives/java

In this example, the lowercase letter "L" at the beginning of the string "lrwxrwxrwx" tells us that "/usr/bin/java" is a symbolic link to the target ..., which is the actual location of the JRE. Note that if the link target is something like "/usr/bin/gij-wrapper-4.1", as is the case in the Ubuntu distribution, this may not yet be the actual location of the JRE. To test this, type:

$ file /usr/bin/gij-wrapper-4.1
/usr/bin/gij-wrapper-4.1: perl script text executable

If the "file program says something to the effect that the link target is a perl or shell script, then this is still not the actual location of the JRE.

$ ls -l /usr/lib/SunJava2-1.4.2/jre/bin/java
...

This tells us that this is the actual location of the JRE. Now you still have to check whether it is present in your PATH variable (see below). In this example, the version number is indicated by the number "1.4.2". If the path to the java program does not contain an indication about its version, then use the "cd" command to navigate to the program. (Note that you should leave off the final "java" in the above path, since it is name of the actual program, not its directory location.):

Checking whether the JRE is Installed Using the "rpm" Program

If your system does not have the "locate" program, or if the "locate" program could not find the JRE, open an interactive shell, type:

$ rpm -q jre

If the "rpm" program responds with a statement such as "package jre is not installed", then it is still possible that it is installed. In this case, try the "find" command.

Checking whether the JRE is Installed Using the "find" Program

If you cannot determine whether the JRE is installed using either the "locate" or the "rpm" programs, then you may also try using the "find" command:

$ find / -iname java -print 2>/dev/null

Depending on your system, it may take a minute or two for this command to finish executing. If the "find" program responds with something like "/usr/lib/SunJava2-1.4.2/jre/bin/java", then it is installed. (Note that the find program might find other instances of the word "java" on your computer, such as "/etc/java". The one you want will end in something like "jre/bin/java".) If the find program does not respond in a similar way, then the Java Runtine Environment is almost certainly not installed on your computer, and you will have to install it (see below).

This last way of finding the JRE may find both the actual location of the JRE and a "symbolic link" (shortcut) to it. When programs such as the JRE are installed, it is common to create such symbolic links to them to provide a unique, unchanging location that can be put in the PATH statement, so that the PATH statement does not have to be modified when the program is subsequently updated: All that is necessary is to change the symbolic link (see below). To determine whether you have found the actual location of the JRE or a symbolic link to it, use the "ls -l" for every location that you found that you think might be where the JRE is located:

$ ls -l /usr/local/bin/java
...

In this example, the lowercase letter "L" in the string "..." and "..." tells us that "/usr/local/bin/java is a symbolic link to the actual location of the JRE. Now, we use the "ls -l" command on the actual location of the JRE:

$ ls -l /usr/lib/SunJava2-1.4.2/jre/bin/java
...

This tells us that this is the actual location of the JRE. It is also possible that Remember that you still have to check whether it is present in your PATH variable (see below). In this example, the version number is indicated by the number "1.4.2". If the path to the java program does not contain an indication about its version, then use the "cd" command to navigate to the program. (Note that you should leave off the final "java" in the above path, since it is name of the actual program, not its directory location.):

$ cd /usr/lib/SunJava2-1.4.2/jre/bin

Then, execute the following command to check the version:

$ ./java -version

Remember to precede the command with "./, in case the current directory is not present in the PATH variable. The java program will respond with something like:

java version "1.4.2_10"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_10-b03)
Java HotSpot(TM) Client VM (build 1.4.2_10-b03, mixed mode)

Make sure that the version number is high enough for whatever Java application you are using that needs the JRE. You might find several different versions of the JRE installed on your computer. In this case, you should probably use the one with the highest version, unless you know a specific reason to use an older one.

Checking the PATH Variable for the JRE

If the JRE is installed on your computer, you should also check whether the java program is present in your PATH variable. (Note that if the JRE is not even installed, there is no point in checking whether the java program is in the PATH variable: First install the JRE, and then perform this check.) To check whether the java program is in your PATH variable, type:

$ which java

If the which program responds the same way that the find program did above (in this example "/usr/lib/SunJava2-1.4.2/jre/bin/java"), then the java program is in your PATH statement. (If you have multiple versions of the JRE installed, also check that the version in the PATH statement is the one you want. You can test this by doing the version test at a command prompt that is in a directory other than the one in which the JRE version you want resides. If the PATH statement contains the wrong version, see below.) If the which program does not find the path to the JRE, you will have to add it to the PATH statement in the files that are executed when you login.

Finding the PATH Statement

The PATH variable is defined by the PATH statement, which is found in the files that are executed when you login. The files that are executed when you login depend on what shell you are using. To determine which shell you are using, type:

$ echo $0

The shell will respond with something like "bash" (Bourne Again SHell) or "sh" (Bourne shell) or "ksh" (Korn shell) or "zsh" (the z shell of Paul Falstad, named after Zhong Shao) or "csh" (C shell). You are probably using the "bash" shell. Now, use a file management program such as Konqueror to explore the files in your home directory. To make sure that you are in your home directory in Konqueror, simply click on the "Home" icon on the toolbar beneath the menu bar. To find your home directory in an interactive shell, type:

$ cd
$ pwd

The shell will respond with the currect directory, which will be your home directory if you have just executed a "cd" command. If you are using a file management program, make sure that it is configured to show "hidden" files (files that begin with a period). To do this in Konqueror, select the menu command "View | Show Hidden Files". If you are doing this in an interactive shell, please note that the command "ls *" or "ls -l *" will not list hidden files; however it will list them if you use the "-a" switch or if you explicitly name them, for example "ls -al" (which will also display a number of hidden directories and other hidden files that you might not know existed!) or "ls .bash_profile" or "ls -ld .bash_profile".

Assuming that you are using the "bash" shell, look for the files ".bash_profile", ".bash_login", and ".profile" (in this order). Note that these files begin with a period ("."). If none of these files exist in your home directory, then create the first of them in your home directory. If one or more of these files does exist, then open it/them in this same order in a text editor (not a word processor such as OpenOffice.org), and look for a statement that says something like "PATH=/bin:/usr/bin:/usr/local/bin:.". Take the first one of these files you find that has a PATH statement, and make a backup copy of it, either in the file management program or in the shell. (Making a backup copy is a good precaution in case you make a bad mistake in updating this file. If that should happen, you can simply delete the file you messed up, and copy your backup copy back to its original name.) To make a backup copy in the shell, type:

$ cp -i .bash_profile .bash_profile.back

(If you find the PATH statement in another file than the one shown in the above statement, then change the above file names accordingly.)

Next, it is necessary to decide exactly what to add to the PATH statement. The simplest thing to do is to put the absolute path to the installed JRE in the PATH statement. However, if you do this, then the next time you upgrade the version of the JRE that is installed on your computer, you will have to update your PATH statement again. If you are comfortable with this, then this is a perfectly acceptable configuration.

Another approach is to create a symbolic link to the JRE in a directory such as "/usr/local/bin/ and to add this symbolic link to the PATH statement. Whenever you upgrade the JRE in the future, all you will have to do is change the symbolic link. The following discussion will explain both approaches. You should decide on one and use it. You may want to read through both approaches before you actually do anything.

Creating a Symbolic Link to the JRE

This approach involves creating a symbolic link (shortcut) to the current version of the JRE, and then putting the symbolic link in your PATH statement. When you upgrade the JRE, you will have to delete the symbolic link to the old JRE and create a new symbolic link to the new JRE.

A symbolic link can be created as follows. Say that the actual location of the JRE is "/usr/lib/SunJava2-1.4.2/jre/bin/java, and you decide to put your symbolic link in the location "/usr/local/bin/java. Then, type:

$ ln -s /usr/lib/SunJava2-1.4.2/jre/bin/java /usr/local/bin/java

If a symbolic link already exists, for example if there is a symbolic link to an older version of the JRE, then you will get an error message such as "...". In this case you will have to delete the existing symbolic link before you can create a new one:

rm 

(Do not worry about the "rm command "following" the link and deleting the actual program: It will delete only the symbolic link.)

Once you have created a symbolic link to the correct version of the JRE, check your work by typing:

$ ls -l /usr/local/bin/java (or whatever symbolic link location you chose)

This command should respond with something like:

lrwxrwxrwx ...

The initial lowercase letter "L" shows that this is a symbolic "link. Now all that is necessary is to add this link to the PATH statement in the login files.

Adding the JRE to the PATH Statement in Login Files

Open the login file in which the PATH statement is defined (the original file, not the backup) in a text editor and add either the java program's path or the symbolic link's path to the end of the PATH statement. If you don't know how to do this, the safest and easiest way to do this is to find the last PATH statement in the file, and to add, on the very next line, the actual location of the JRE:

PATH=${PATH}:/usr/lib/SunJava2-1.4.2/jre/bin

Here "/usr/lib/SunJava2-1.4.2/jre/bin" is the path to the java program that you found above. On your computer it will be different. Remember to leave off the final "/java", since that is the actual program, not the path to it. Don't forget the colon. When you are done, save the file. Alternatively, if you want to add a symbolic link instead of the actual location of the JRE, add the following:

PATH=${PATH}:/usr/local/bin

After you have added either the actual location of the JRE or a symbolic link to it, open a new interactive shell and repeat the above test ("which java") to make sure that java is now in the PATH statement, and also test that it is the correct version of the JRE, as explained above.

If you had to create one of the login files (e.g., ".bash_profile"), then obviously it will be empty and you will not be able to find any PATH statement. In this case, simply add the PATH statement given above someplace to the appropriate login file.

If your shell is "sh", then look in your home directory for the file ".profile". If it does not exist, then create it. If it does exist, search it for the last PATH statement, and make the same change as was explained above for the bash shell.

If your shell is "ksh", then look in your home directory for the files ".kshrc" and ".profile" (in this order). If neither of them exists, create them. If these files do exist, search them for the PATH statement, and change the file with the PATH statement as explained above for the bash shell. Note that the PATH statement will probably begin with the word "export", for example:

export PATH=/bin:/usr/bin:/usr/local/bin:.

In this case, it is also necessary to add the word "export" to the beginning of the statement that you add:

export PATH=${PATH}:/usr/lib/SunJava2-1.4.2/jre/bin

If you had to create the files ".kshrc" and ".profile", add the above statement to the ".kshrc" file and the following statement to the ".profile" file:

export ENV=~/.kshrc

If your shell is "zsh", then the file which should contain the PATH variable assignment is called ".zshenv", so this is where you should search for it first. However, it is possible that it could be set in one of the files ".zshrc", ".zlogin", or ".zprofile". I recommend that you make the change to the PATH variable assignment in the same file where you find it. If you have to create these files, then you should put the PATH variable assignment in the file called ".zshenv".

If your shell is "csh", then repent.

If you are having trouble finding the PATH statement in your login files, first make sure that you really are looking in your home directory. If are still having trouble, try the following command in an interactive shell:

$ grep PATH .*

Remember that the shell is case-sensitive, and that the word "PATH" must be uppercase.

Note that if you have multiple versions of the JRE on your computer and the wrong version is in the PATH statement, then you cannot simply add a statement as described above. Instead, you must actually edit the PATH statement. The reason why is that the shell will use the first instance of the java program that it finds in the PATH statement.

Editing the PATH Statement in Login Files

To edit the PATH statement, use the above procedures to find the java program's path in the PATH statement and make a backup copy of the file that contains it, as described above. Next, use a text editor to open the file that contains the java program's PATH statement, and make a backup copy of the line that contains the wrong PATH statement. To do this, first copy the line that contains the wrong PATH statement:

PATH=/bin:/usr/bin:/usr/local/bin:/wrong/jre/path:.
PATH=/bin:/usr/bin:/usr/local/bin:/wrong/jre/path:.

Next, add "# " to the beginning of the first line (this deactivates it):

# PATH=/bin:/usr/bin:/usr/local/bin:/wrong/jre/path:.
PATH=/bin:/usr/bin:/usr/local/bin:/wrong/jre/path:.

(Having a backup copy of the line you are going to change is a good idea for two reasons. First, you can look back and forth between the backup copy of the line and the line you are editing, to make sure that you don't make a mistake. Second, if you do make a bad mistake, you can make a fresh copy of the line and start over.)

Now, carefully change the wrong JRE path to the correct one. Make sure to do this in the active PATH statement (the one without the "# "), and to leave a colon (":") on either side of the path:

# PATH=/bin:/usr/bin:/usr/local/bin:/wrong/jre/path:.
PATH=/bin:/usr/bin:/usr/local/bin:/correct/jre/path:.

The correct JRE path could either be the actual location of the JRE or the symbolic link to it. When you are done, save the file, open a new interactive shell, and repeat the above test ("which java") to make sure that the correct version of the JRE is now in the PATH statement.

Getting and Installing Java

If JRE is not installed on your computer, the first thing to do is check whether your distribution's package management program will install it for you automatically off your installation media, which probably include it on a CD-ROM / DVD-ROM of "extras", etc. If this is not the case, or if you have a fairly old distribution, then you can download the JRE free from Sun Microsystems. Sun's Java website should recognize your platform as Linux automatically, and instructions are provided there, so they will not be repeated here. I recommend getting the RPM download unless you know that you do not want an RPM. I should also point out that unless you know that you have a 64-bit AMD processor, don't select one of the "Linux AMD64" downloads. Follow the instructions carefully, and then repeat the tests above to verify that the JRE is installed and that the java program is in your PATH statement.

Configuring the Java Plugin

Note that the "Enable and Configure" instructions on Sun's web site about installing the Java plugin for Mozilla can be a little confusing, and need to be read very carefully. In particular, different versions of Mozilla / Netscape need to have different plugins installed. If you install the wrong one, Mozilla might crash when you try to use the Java plugin. The different versions of the plugin will be in subdirectories of a directory called something like "/usr/java/jre1.5.0/plugin/i386" (this is for JRE 1.5 on the Intel platform on my computer; it will probably be different on your computer). There will probably be two different subdirectories in this directory, for example "ns7" and "ns7-gcc29". Determining which one you need can be a little difficult, but you can try typing the command "rpm -q gcc". If your system responds with something like "gcc-3.3.1-24", then you should use the plugin in the "ns7" directory. If your system gives a lower number such as gcc-2.9, then try the "ns7-gcc29" directory. If you have trouble determining which one to use, simply try them one after the other and then verify that your installation is correct. Enough people have had trouble with this that it has been reported as Mozilla bug 209904, although it is not really a bug.

Click here to return to Thomas Hedden's home page.

Copyright © 2006-2017 Thomas Hedden

This page is viewable with any browser.