Setting Up Your Environment To Run Java

This document describes how to set environment variables for running Java correctly.

The description below assumes that you have installed Java in the default location. If you used the -r option to inst or swmgr to install Java in an alternate location, then you should prepend that location to all instances of /usr/java below.

The setenv commands given below assume that your command shell is csh or tcsh. If you are using a different shell, you will have to modify the commands accordingly.

PATH

All the JDK tools are located in /usr/java/bin. You can explicitly invoke them from there, or you can put that directory in your PATH with the following command:

• setenv PATH $PATH:/usr/java/bin

CLASSPATH

CLASSPATH is the environment variable that several of the JDK tools use to determine where to load application classes from. It should be set to a colon-separated list of directories, for example:

• setenv CLASSPATH .:/usr/people/johndoe/java/classes

It should include the locations of any Java packages/applications on your machine that you would like to be able to use from any directory. If there are no such locations, it is best not to set CLASSPATH at all. If you do set it, there are two things you should not include:

• Location of system classes
  
  

  The JDK tools will automatically find the correct system class location, such as /usr/java/classes, corresponding to the location of the tools themselves, so you do not need to include such directories in your CLASSPATH. If you have multiple Java installations (for example, both 1.0.2- and 1.1-based versions of our Java software, as well as netscape), including system class locations in your CLASSPATH may in fact cause incompatibilities, since you may mix a tool from one installation with classes from another.

• Locations of applet classes
  
  

  Applet classes are meant to be loaded from the applet's CODEBASE (the directory of the HTML file if no CODEBASE tag is present), not from the CLASSPATH. If you have applet classes in a directory which is in your CLASSPATH, those classes will be allowed to bypass the normal applet security restrictions.

Should your CLASSPATH include "." (the current directory)?

• If you are running applets, this may not be a good idea, since the current directory may coincide with the applet's CODEBASE.
  
  
• If you always want to be able to run applications residing in your current working directory and you are setting the CLASSPATH variable at all, it must include ".".

LD_LIBRARY_PATH

LD_LIBRARY_PATH is the environment variable that java uses to determine where to load native code DSO's from. It should be set to a colon-separated list of directories, for example:

• setenv LD_LIBRARY_PATH .:/usr/people/johndoe/java/lib

It should include the directories containing native code DSO's for any Java packages/applications on your machine that you would like to be able to use from any directory. If there are no such locations, it is best not to set LD_LIBRARY_PATH at all. If you do set it, you should not include locations of system DSO's (e.g., /usr/java/lib/sgi or /usr/lib) for reasons similar to those mentioned above for CLASSPATH.

If you always want to be able to run applications containing native code residing in your current working directory, you must include "." in your LD_LIBRARY_PATH.

Java and other Java-based names are trademarks of Sun Microsystems, Inc., and refer to Sun's family of Java-branded technologies. Sun, Sun Microsystems, and the Sun Logo are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries.