When the Java compiler/interpreter is executed, it looks for any packages in the directories that are mentioned in the CLASSPATH. By default, the CLASSPATH is empty, and if this is the case it will instead look for packages in the current directory.

So, if you have put some class/interface declarations into a package called utils.dateutils, the utils directory must be a subdirectory of the current directory.

Although the use of a subdirectory of the current directory is a useful place to hide the files of a package, this mechanism can be too restrictive. For example, if you build a number of useful classes and store them in one or more packages, it would be useful to put these in a standard place. The Java compiler/interpreter allows you to specify other directories in which it can find packages by setting the CLASSPATH.

The way in which this is done depends on whether you are using a Unix or an MS-DOS command line. When using Unix, then for csh/tcsh, an example is:

setenv CLASSPATH .:/users/dcl0bjc/classes:/users/dxy3abc/public_html

or, if you are using sh, ksh or bash, this would be:

CLASSPATH=.:/users/dcl0bjc/classes:/users/dxy3abc/public_html
export CLASSPATH

At an MS-DOS prompt, you could type something like:

set CLASSPATH=.;C:\project\classes;D:\myjava

Note that for Unix, items in the list of directories are separated by a colon, whereas the semicolon is used at an MS-DOS prompt. If you also want the compiler/interpreter to look in the current directory, then it must be included in the CLASSPATH: a dot can be used in the CLASSPATH in order to refer to this directory.

The Java compiler/interpreter knows how to find the packages that form part of Java's Development Kit, and so there is no need to include anything in the CLASSPATH to help the compiler/interpreter find these packages. Note: this was not the case with earlier versions of the Development Kit.