The CLASSPATH environment variable is used by Java to determine where to look for classes referenced by a program. If, for example, you have an import statement for my.package.Foo, the compiler and JVM need to know where to find the my/package/Foo class.
In the CLASSPATH, you do not need to specify the location of normal J2SE packages and classes such as java.util or java.io.IOException.
You also do not need an entry in the CLASSPATH for packages and classes that you place in the ext directory (normally found in a directory such as C:\j2sdk\jre\lib\ext). Java will automatically look in that directory. So, if you drop your JAR files into the ext directory or build your directory structure off the ext directory, you will not need to do anything with setting the CLASSPATH. But this directory was intended for official Java extensions from Sun. Its use by unofficial Java extensions isn't recommended.
Note that the CLASSPATH environment variable can specify the location of classes in directories and in JAR files (and even in ZIP files).
If you are trying to locate a jar file, then specify the entire path and jar file name in the CLASSPATH. (Example: CLASSPATH=C:\myfile\myjars\myjar.jar).
If you are trying to locate classes in a directory, then specify the path up to but not including the name of the package the classes are in. (If the classes are in a package called my.package and they are located in a directory called C:\myclasses\here\my\package, you would set the classpath to be CLASSPATH=C:\myclasses\here)
The classpath for both entries would be CLASSPATH=C:\myfile\myjars\myjar.jar;C:\myclasses\here.
Be careful relying on the CLASSPATH too much. It can be convenient during development, but is often much less useful in a production situation.
You do not always have full control over the CLASSPATH.
If you package up your application in executable JarFiles, the system CLASSPATH is simply ignored. Instead, you should specify a Class-Path manifest attribute.
In J2EE development, you should generally not modify the CLASSPATH or put application jars (except JDBC drivers) in the lib directories of your application server or jre/lib/ext. Doing so may introduce odd dependencies between your web applications and set you up for classloader problems. -- PeterDenHaan
Instructions on Setting the CLASSPATH on different Operating Systems
For Windows XP/2000/NT
Open the System Properties window (by right-clicking on My Computer and selecting Properties, or through the Control Panel - Start -> Control Panel -> System).
On the Advanced tab, click the Environment Variables button.
On the Environment Variables windows, if a CLASSPATH variable is already defined, then select it and click Edit. If one is not defined, then click the New button.
On the User Variable window, the variable name should be CLASSPATH. Set the value as appropriate. See the description of the value at the top of this page.
Note that different class file location values should be seperated with a semicolon on a Windows machine (not with a colon as is used with Linux).
For Windows ME/98/95
Open the C:\autoexec.bat file in your preferred text editor. Someplace in the file, add something similar to the following line.
Note that Foo.jar probably isn't the actual value that you'd like to add. Just specify all of the class file locations that you'd like included, separating each different location with a semicolon. See the description of the value at the top of this page.
If your autoexec.bat file already specifies a CLASSPATH value, then you might want to add a line similar to the following line after the existing CLASSPATH settings.
The %CLASSPATH% part just specifies to use whatever the previous value for this variable was here. Kind of like saying i = i + 1; in Java.
For Linux and other Unix variants
If you are using bash as your command shell, open .bash_profile in your favorite text editor. You should already have one in your home directory. If not, you can create it. If you use another shell (i.e. ksh, csh, etc.), they run similar profile scripts when loging in. I don't know what the file names are for these other shells, though. If all else fails, you should be able to use .profile instead, which is usually executed no matter which shell you use. For my text editor, I like emacs, so the command line looks something like this:
The syntax is similar to the autoexec.bat file in Windows 9x/ME. Add something similar to the following lines to the .bash_profile file:
Notice that subdirectories are separated with a forward slash (/) and complete paths are separated with a colon (. This is typical for any Unix-like operating system.
There are no spaces before or after the = sign.
The . at the beginning of the list includes the current directory in the class path. This is necessary for Java to be able to find .java and .class files in the current directory.
The second "entry" refers to a jar file. Use an appropriate path and file name here.
The last "entry" refers to the base directory where other classes can be found. Most likely, it contains other subdirectories that correspond to appropriate package names.