Class pathcan be set using either by using the
when calling an SDK tool (the preferred method) or by using the
environment variable. Setting the class path by using 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.
;classpath3... or we can use like this
C:> set CLASSPATH=classpath1
where: sdkTool: It is a command-line tool, similar to javadoc, javac and classpaths are the class paths of the .jar, .zip, or .class files.
Suppose there is a package structure called org.roseindia that contains the following classes: MyApp as the main class, ClassA, and the ClassB, and the application directory named Application is inside the D: directory as D:\Application (on Windows).
Here is the directory structure of our application.
| ---> Mylib.jar
To set the classpath for this application we use the following command:
|java -classpath D:\Application org.roseindia.MyApp|
where -classpath D:\Application sets the path to the packing we are using in the program. and org.roseindia.MyApp is the path of the main class.
Setting the path by using the environment variable
There is an alternate of the setting the classpath by using the environment. Here we are setting the classpath by using the environment various for the Window operating system of the above mentioned application.
Setting the path for a Jar file:
Now, suppose our program uses the library that is enclosed in a Jar file called Mylib.jar then we have to use the command line option given below:
|java -classpath D:\Application;
or we can also use it like the one given below:
Setting the path in a Manifest file
Suppose we have bind up our program in a Jar file named MyApp.jar and put it inside a Application directory parallel to the lib directory and we have defined a manifest file in this jar file with the following definition:
It is important to note that the manifest file ends with either in a carriage return or in a new line.
We can launch the program by using the following command:
|java -jar D:\Application\MyApp.jar|
Defining the Main class, the Classpath to the program classes, and the support library classes is not necessary as they are already defined in the manifest file.
We can specify multiple library JAR files in the manifest file simply by separating the multiple entries with a space by using the following command:
|Class-Path: lib/Mylib.jar lib/Mylib1.jar|
Multiple path entries are separated by semi-colons. With the
command, it's important to omit spaces from around the equals sign (=).
The default class path is the current directory. Setting the
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 neither a directory nor an archive (.zip or .jar file) are ignored.
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
CLASSPATH settings that are no longer needed. You
should remove any settings that are not application-specific, such as
Some third-party applications that use the Java Virtual Machine may modify your
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
environment variable. Using the
-classpath option is preferred
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.
>/classesentry 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
>/classesdirectory 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
-classpathoption which replaces the path or paths specified by the
CLASSPATHenvironment 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
-cpoption, as well. This option is an abbreviation for
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
-classpathcommand-line option, as explained in the previous section. This section shows you how to set the
CLASSPATHenvironment variable if you want to do that, or clear settings left over from a previous installation.
CLASSPATHenvironment variable is modified with the set command. The format is:1
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 than
CLASSPATHenvironment 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
C:> set CLASSPATH=
This command unsets
CLASSPATHfor the current command prompt window only. You should also delete or modify your startup settings to ensure that you have the right
CLASSPATHsettings in future sessions.
Changing Startup SettingsIf the
CLASSPATHvariable 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. Other (Windows NT, Windows 2000, ...) The CLASSPATH environment variable can be set using the System utility in the Control Panel.
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.Buttonis always specified as
For example, suppose you want the Java runtime to find a class named
Cool.classin the package
utility.myapp. If the path to that directory is
C:\java\MyClasses\utility\myapp, you would set the class path so that it contains
To run that app, you could use the following JVM command:
C:> java -classpath C:\java\MyClasses utility.myapp.Cool4
When the app runs, the JVM uses the class path settings to find any other classes defined in the
utility.myapppackage that are used by the
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\utilityand 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.)5
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
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:6
C:> java -classpath C:\java\MyClasses\myclasses.jar utility.myapp.Cool
To find class files in the directory
C:\java\MyClassesas well as classes in
C:\java\OtherClasses, you would set the class path to:
C:> java -classpath C:\java\MyClasses;C:\java\OtherClasses ...
Note that the two paths are separated by a semicolon.
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