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/lib/classes.zip, 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.x- and 1.1.x-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 ".".

Should you use the -classpath option?

• Most of the time, no. The CLASSPATH environment variable gives java additional places to look for classes beyond the normal location of the system classes, whereas the -classpath option specifies a complete set of places to look, so it must include the location of the system classes. This is not usually the desired functionality, and requires you to provide platform- and release-specific information (the location of the system classes).
  
  
• One case where you may need to use it is when using javac, when you want the class path for the compilation (given by the -classpath option to javac) to be different from the class path used to run javac (given by the CLASSPATH environment variable).
  
  
• If you find yourself in a situation where you must use the -classpath option, you will need to know where the system classes reside. The correct class path fragment to locate all the system classes is

  /usr/java/classes:/usr/java/lib/rt.jar:/usr/java/lib/i18n.jar:/usr/java/lib/classes.zip
  

LD_LIBRARY_PATH and LD_LIBRARYN32_PATH

LD_LIBRARY_PATH and LD_LIBRARYN32_PATH are the environment variables that the Java software uses to determine where to load o32 and n32 native code DSO's from, respectively (for an explanation of o32/n32 and Java), see New Features. When running the o32 version of any Java software, any DSO's you want to use must be o32 and must be in a directory in your LD_LIBRARY_PATH. Likewise, when running the n32 version of any Java software, any DSO's you want to use must be n32 and must be in a directory in your LD_LIBRARYN32_PATH.

LD_LIBRARY_PATH should be set to a colon-separated list of directories. For example, you might use this command if you use csh or tcsh:

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

It should include the directories containing o32 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/green_threads or /usr/lib) for reasons analogous to those mentioned above for CLASSPATH.

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

LD_LIBRARYN32_PATH is the environment variable used for n32 DSO's; the rules for its use are the same as those given for LD_LIBRARY_PATH.

SGI_ABI

This environment variable is discussed in New Features.

THREADS_FLAG

This environment variable is discussed in New Features.

The Invocation API

Setting up your environment for running programs that use the Invocation API is more complicated. See the section on the Invocation API in our Native Code documentation for more details.

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.