Setting the class path Synopsis The class path is the path that the Java runtime environment searches for classes and other resource files. The class search path (more commonly known by the shorter name, "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. % sdkTool -classpath classpath1:classpath2... -or- % setenv CLASSPATH classpath1:classpath2... where: sdkTool A command-line tool, such as java, javac, or javadoc. For a listing, see SDK Tools. classpath1:classpath2 Class paths to the .jar, .zip or .class files. Each classpath 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 class path ends with the name of the .zip or .jar file. For .class files in an unnamed package, the class path ends with the directory that contains the .class files. For .class files in a named package, the class path ends with the directory that contains the "root" package (the first package in the full package name). Multiple path entries are separated by colons. 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 neither directories nor archives (.zip or .jar files) are ignored. Description The class path tells the SDK tools and applications where to find third-party and user-defined classes -- that is, classes that are not 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 software, 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 SDK 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 SDK software included a <jdk-dir>/classes entry in the default class path. That directory exists for use by the SDK software, and should not be used for application classes. Application classes should be placed in a directory outside of the SDK direcotry hierarchy. That way, installing a new development environment 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 Java 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 In csh, the CLASSPATH environment variable is modified with the setenv command. The format is: setenv CLASSPATH path1:path2 In sh, the CLASSPATH environment variable can be modified with these commands: CLASSPATH = path1:path2:... export CLASSPATH 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 in csh by using: unsetenv CLASSPATH In sh, you would use: unset CLASSPATH These commands unset CLASSPATH for the current shell 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 the shell you are running: Shell Startup Script csh, tcsh Examine your .cshrc file for the setenv command. sh, ksh Examine your .profile file for the export command. 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 is /java/MyClasses/utility/myapp, you would set the class path so that it contains /java/MyClasses. To run that app, you could use the following JVM command: % java -classpath /java/MyClasses utility.myapp.Cool 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 /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 /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, /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: % java -classpath /java/MyClasses/myclasses.jar utility.myapp.Cool Multiple specifications To find class files in the directory /java/MyClasses as well as classes in /java/OtherClasses, you would set the class path to: % java -classpath /java/MyClasses:/java/OtherClasses ... Note that the two paths are separated by a colon. 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 /java/MyClasses. Only if it doesn't find a class with the proper name in that directory will the interpreter look in the /java/OtherClasses directory.
Problems Running the Application Running the Dive Log application is similar to compiling, but troubleshooting can be more difficult. If your classes compile without error, but the application does not run correctly, determining the problem can be frustrating and difficult. Below are some of the more common problems.Problem 1: Trying to Run Only DiveLog.javaIf you run the DiveLog class and this error appeared on the command line: Exception in thread "main" java.lang.NoClassDefFoundError: DiveLog/javaYou probably tried to run the application with: java DiveLogFor a single class application that command normally works. For a multi-class, packaged application it does not.Solution to Problem 1The rules for compiling the Dive Log apply to running it as well.To run a packaged application you must include the classpath which points to, but does not include, the directory where the classes live. Do not include the package name with the dot, though. If your Dive Log files are in the following directory: C:\Applications\divelogStep 1: cd to the divelog directory. Step 2: Run the command to compile the Dive Log application with the following:java -classpath C:\Applications\ divelog.DiveLogNote the command to run is slightly different from the compile command:javac to compile java to runAlso, note the space after C:\Applications\ Problem 2: Naming the Directory IncorrectlySimilar to problem 1, the application needs to know where the class files are to be found. If you leave off the directory name in front of the file name, such as:java -classpath C:\Applications\ DiveLog.javayou get an error similar to:Exception in thread "main" java.lang.NoClassDefFoundError: DiveLog/javaYou also get this error if you include the directory where the class files live in the classpath. Remember, you must cd into the divelog directory, then name the directory as a part of the class name to be run: java -classpath C:\Applications\ divelog.DiveLogIf you still have problems compiling or running the Dive Log application after reading this page, use the Reader Feedback form. Include the command you used, and the error it generated. Problems and solutions will be added to this page to help all readers.
试一下
java xxxx
时，其实它是执行名字为xxxx的这个类，而并不是xxxx.class这个文件，这和C/c++以及其他语言所完全不同的。所以，当java虚拟机不能找到xxxx这个类（包括它引用的其他类）时（java自动在你所设定的类搜索路径里搜索，类搜索路径在系统classpath里设置，但是你永远也无法确定和涵盖你在这个系统里面可能产生的所有类搜索路径），它就会报告错误：Exception in thread "main" java.lang.NoClassDefFoundError: d:\j2sdk\helloworld/class
此时，你可以用如下办法来解决：
假设你的java程序编译成功并放在 /tmp目录下，文件名为：helloworld.class
(注意大小写，并且假设你没有自定义包）
java -classpath /tmp helloworld如果你自定义了包，假设是package myjava,并且位于/tmp下，类文件名还是同上：
java -classpath /tmp myjava.helloworld这是最简单的情况，如果此程序中还引用了大量的其他分布在各个不同位置和包的类则需要另外考虑。但是这种原因根本上就是找不到类定义的明确表现。
Synopsis
The class path is the path that the Java runtime environment searches for classes and other resource files. The class search path (more commonly known by the shorter name, "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.
% sdkTool -classpath classpath1:classpath2... -or- % setenv CLASSPATH classpath1:classpath2... where: sdkTool
A command-line tool, such as java, javac, or javadoc. For a listing, see SDK Tools. classpath1:classpath2
Class paths to the .jar, .zip or .class files. Each classpath 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 class path ends with the name of the .zip or .jar file.
For .class files in an unnamed package, the class path ends with the directory that contains the .class files.
For .class files in a named package, the class path ends with the directory that contains the "root" package (the first package in the full package name).
Multiple path entries are separated by colons. 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 neither directories nor archives (.zip or .jar files) are ignored. Description
The class path tells the SDK tools and applications where to find third-party and user-defined classes -- that is, classes that are not 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 software, 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 SDK 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 SDK software included a <jdk-dir>/classes entry in the default class path. That directory exists for use by the SDK software, and should not be used for application classes. Application classes should be placed in a directory outside of the SDK direcotry hierarchy. That way, installing a new development environment 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.
The Java 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
In csh, the CLASSPATH environment variable is modified with the setenv command. The format is:
setenv CLASSPATH path1:path2
In sh, the CLASSPATH environment variable can be modified with these commands:
CLASSPATH = path1:path2:...
export CLASSPATH 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 in csh by using: unsetenv CLASSPATH
In sh, you would use: unset CLASSPATH
These commands unset CLASSPATH for the current shell 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 the shell you are running:
Shell Startup Script
csh, tcsh Examine your .cshrc file for the setenv command.
sh, ksh Examine your .profile file for the export command.
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 is /java/MyClasses/utility/myapp, you would set the class path so that it contains /java/MyClasses. To run that app, you could use the following JVM command: % java -classpath /java/MyClasses utility.myapp.Cool 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 /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 /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, /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: % java -classpath /java/MyClasses/myclasses.jar utility.myapp.Cool
Multiple specifications
To find class files in the directory /java/MyClasses as well as classes in /java/OtherClasses, you would set the class path to: % java -classpath /java/MyClasses:/java/OtherClasses ...
Note that the two paths are separated by a colon. 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 /java/MyClasses. Only if it doesn't find a class with the proper name in that directory will the interpreter look in the /java/OtherClasses directory.
Running the Dive Log application is similar to compiling, but troubleshooting can be more difficult. If your classes compile without error, but the application does not run correctly, determining the problem can be frustrating and difficult. Below are some of the more common problems.Problem 1: Trying to Run Only DiveLog.javaIf you run the DiveLog class and this error appeared on the command line: Exception in thread "main" java.lang.NoClassDefFoundError: DiveLog/javaYou probably tried to run the application with: java DiveLogFor a single class application that command normally works. For a multi-class, packaged application it does not.Solution to Problem 1The rules for compiling the Dive Log apply to running it as well.To run a packaged application you must include the classpath which points to, but does not include, the directory where the classes live. Do not include the package name with the dot, though. If your Dive Log files are in the following directory: C:\Applications\divelogStep 1: cd to the divelog directory.
Step 2: Run the command to compile the Dive Log application with the following:java -classpath C:\Applications\ divelog.DiveLogNote the command to run is slightly different from the compile command:javac to compile
java to runAlso, note the space after C:\Applications\ Problem 2: Naming the Directory IncorrectlySimilar to problem 1, the application needs to know where the class files are to be found. If you leave off the directory name in front of the file name, such as:java -classpath C:\Applications\ DiveLog.javayou get an error similar to:Exception in thread "main" java.lang.NoClassDefFoundError: DiveLog/javaYou also get this error if you include the directory where the class files live in the classpath. Remember, you must cd into the divelog directory, then name the directory as a part of the class name to be run: java -classpath C:\Applications\ divelog.DiveLogIf you still have problems compiling or running the Dive Log application after reading this page, use the Reader Feedback form. Include the command you used, and the error it generated. Problems and solutions will be added to this page to help all readers.
.;classpath=.;c:\j2sdk1.4\lib\tools.jar;c:\j2sdk1.4\jre\lib\rt.jar