The class path can be set using either the
-classpath option when calling an SDK tool (the
preferred method) or by setting the CLASSPATH environment
variable. The -classpath option is preferred because you
can set it individually for each application without affecting other
applications and without other applications modifying its value.
C:> sdkTool-classpath path1;path2...
-or-
C:> set CLASSPATH=path1;path2...
where:
sdkTool
A command-line tool, such as java, javac, or
javadoc. For a listing, see
SDK Tools.
path1;path2
Paths to the .jar, .zip or .class files.
Each path should end with a filename or directory depending on
what you are setting the class path to:
For a .jar or .zip file that contains .class files,
the path ends with the name of the .zip or .jar file.
For .class files in an unnamed package, the path ends
with the directory that contains the .class files.
For .class files in a named package, the path ends with
the directory that contains the "root" package (the
first package in the full package name).
Multiple path entries are separated by semi-colons.
With the set command, it's important to omit
spaces from around the equals sign (=).
The default class path is the current directory. Setting the CLASSPATH
variable or using the -classpath command-line option overrides
that default, so if you want to include the current directory in the search
path, you must include "." in the new settings.
Classpath entries that are not either a directory or an archive (.zip or
.jar file) are ignored.
Description
The class path tells SDK tools and applications where to find
third-party and user-defined classes -- that is, classes that
are not Java
extensions
or part of the Java platform. The class path needs to find any
classes you've compiled with the javac compiler -- its default
is the current directory to conveniently enable those classes to
be found.
Java 2 SDK, the JVM and other SDK tools find classes by searching
the Java platform (bootstrap) classes, any extension classes,
and the class path, in that order. (For details on the search
strategy, see
How Classes Are Found.)
Class libraries for most applications will want to take
advantage of the extensions
mechanism. You only need to set the class path when you
want to load a class that's (a) not in the current
directory or in any of its subdirectories, and (b) not in a
location specified by the extensions mechanism.
If you are upgrading from an older version of the SDK, your
startup settings may include CLASSPATH settings that are no
longer needed. You should remove any settings that are not
application-specific, such as classes.zip.
Some third-party applications that use
the Java Virtual Machine may modify your CLASSPATH environment
variable to include the libaries they use. Such settings can
remain.
You can change the class path by using the Java tools'
-classpath option when you invoke
the JVM or other SDK tools or by using the
CLASSPATH environment variable.
Using the -classpath option is preferred
over setting CLASSPATH environment variable because
you can set it individually for each application without
affecting other applications and without other applications
modifying its value.
Classes can be stored either in directories (folders) or in
archive files. The Java platform classes are stored in
rt.jar. For more details on archives
and information on how the class path works, see
Understanding the class path and package
names near the end of this document.
Important Note: Some older versions of the JDK sofware included
a <jdk-dir>/classes entry
in the default
class path. That directory exists for use by the JDK software, and
should not be used for application classes. Application
classes should be placed in a directory outside of the
JDK directory hierarcy. That way, installing a new JDK does not force you to
reinstall application classes. For compatibility with older
versions, applications that use the
<jdk-dir>/classes
directory as a class
library will run in the current version, but there is no
guarantee that they will run in future versions.
Using the SDK tools' -classpath option
The SDK tools java, jdb,
javac, and javah have a -classpath option
which replaces the path or paths specified by the CLASSPATH
environment variable while the tool runs. This is the
recommended option for changing class path settings, because
each application can have the class path it needs without
interfering with any other application.
The runtime tool java
has a -cp option, as well. This option is an abbreviation
for -classpath.
For very special cases, both java and javac
have options that let you change the path they use to find their own class
libraries. The vast majority of users will never to need to use those options,
however.
Using the CLASSPATH environment variable
In general, you will want to use the -classpath
command-line option, as explained in the previous
section. This section shows you how to set the CLASSPATH
environment variable if you want to do that, or clear settings
left over from a previous installation.
Setting CLASSPATH
The CLASSPATH environment variable is modified with
the set command. The format is:
set CLASSPATH=path1;path2 ...
The paths should begin with the letter specifying the drive,
for example, C:\. That way, the
classes will still be found if you happen to switch to a
different drive. (If the path entries start with backslash (\)
and you are on drive D:, for example, then the classes will
be expected on D:, rather thanC:.)
Clearing CLASSPATH
If your CLASSPATH environment variable has been set to a value
that is not correct, or if your startup file or script is
setting an incorrect path, you can unset CLASSPATH by using:
C:> set CLASSPATH=
This command unsets CLASSPATH for the current command prompt window
only. You should also delete or modify your startup settings
to ensure that you have the right CLASSPATH settings in future
sessions.
Changing Startup Settings
If the CLASSPATH variable is set at system startup, the place
to look for it depends on your operating system:
Operating System
Method
Windows 95 and 98
Examine autoexec.bat for the set command.
Windows NT
Start the Control Panel,
select System, click the Environment tab and, in the
User Variables section, examine the CLASSPATH variable.
Understanding the class path and package names
Java classes are organized into packages which are mapped to
directories in the file system. But, unlike the file system,
whenever you specify a package name, you specify the
whole package name -- never part of it. For example,
the package name for java.awt.Button is always
specified as java.awt.
For example, suppose you want the Java runtime to find a class
named Cool.class in the package utility.myapp.
If the path to that directory
isC:\java\MyClasses\utility\myapp, you
would set the class path so that it contains C:\java\MyClasses.
To run that app, you could use the following JVM command:
When the app runs, the JVM uses the class path settings to
find any other classes defined in the utility.myapp
package that are used by the Cool class.
Note that the entire package name is specified in the command.
It is not possible, for example, to set the class path so it
contains C:\java\MyClasses\utility
and use the command java myapp.Cool. The class
would not be found.
(You may be wondering what defines the package name for a
class. The answer is that the package name is part of the
class and cannot be modified, except by recompiling the
class.)
Note: An interesting consequence of the package
specification mechanism is that files which are part of the
same package may actually exist in different directories. The
package name will be the same for each class, but the path to
each file may start from a different directory in the class
path.
Folders and archive files
When classes are stored in a directory (folder), like
c:\java\MyClasses\utility\myapp, then the
class path entry points to the directory that contains the
first element of the package name. (in this case,
C:\java\MyClasses, since the package name
is utility.myapp.)
But when classes are stored in an archive file (a .zip or .jar
file) the class path entry is the path to and including the .zip
or .jar file. For example, to use a class library that is in a .jar
file, the command would look something like this:
Note that the two paths are separated by a semicolon.
Specification order
The order in which you specify multiple class path entries is
important. The Java interpreter will look for classes in the
directories in the order they appear in the class path variable.
In the example above, the Java interpreter will first look for a
needed class in the directory
C:\java\MyClasses. Only if it doesn't find a
class with the proper name in that directory will the
interpreter look in the C:\java\OtherClasses
directory.