ClassPath

Whenever an SDK tool or Java application refers to a third party or user defined class, the Java runtime environment searches for the class in the class path. The class path is a list of directories, JAR or ZIP files. The standard java launcher command from the J2SDK^? takes a -classpath option.

The term is used more loosely to refer to the locations where classes are searched for in other kinds of applications, such as applets or web applications. Typically the classes are packaged in JARs. When compiling Java source code, the class path typically specifies the root directory containing the directory of the top level package. For example, if you have a class called Foo in the package com.acme, the "com" portion would be mapped to the "com" directory and "acme" to the "acme" subdirectory under "com". If you put the "com" directory into a directory called /home/john/projects (Unix), then you would set the classpath to /home/john/projects in order for the Java compiler (javac) to find your source files. For Windows systems, if you put the "com" directory into c:\projects then you would set the classpath to c:\projects.

It is also recommended to find (read-only) resources, such as images or XML data, in the class path, just like bytecode class files. The method Class.getResource (and some related methods) are appropriate for finding such resources. When you access resources this way, your application does not need to refer to absolute file names (or rely on the process' current working directory), and can be more easily packaged for deployment in an applet, web application, executable JAR file, JavaWebStart package, etc.

If you create your own class loaders, you can load classes from anywhere you like, so the meaning of class path is less precise in this case. See Classloaders for information about class loaders.

Did you mean to look at the GnuClassPath page?

Also See

• Setting the class path on Solaris and Linux
• Setting the class path on Windows
• How Classes are Found
• The Java Extension Mechanism
• Identifying classpath conflicts
• Jarhoo - online index of jar files and classes

Discussion about ClassPath

rickcarson:

If you are having troubles with the classpath consider the much easier alternative of putting Jars (which you are not actively working on - especially JDBC drivers, XML parsers etc) in the /lib/ext folder of your JRE.

Classpaths are important for versioning issues - such as when you have multiple different apps to support which each use a different version of the JDK, or if you are using libraries which require different versions of the same XML parser.

The easiest way to deploy an application is to bundle it and all its resources as a single Jar and install it in the /lib/ext directory.

I used to curse long classpathes, when your app needs a dozen different jars. Then I discovered Class-Path in the jar manifest. Now I put the dependencies into the jars. The best thing is the way they daisy-chain from one jar to another .

When getting classpath errors (java.lang.NoClassDefFoundError or java.lang.ClassNotFoundException messages), try http://www.jarhoo.com for help discovering which jar file contains the relevant class.