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:
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.1.x- and 1.2.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.
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)?
CODEBASE
.
CLASSPATH
variable at all, it must include
".".
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 MIPS
ABI's). 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 MIPS ABI's.
THREADS_FLAG
This environment variable is discussed in Threads.
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.