Many implementations of the Java platform rely on hierarchical file systems to manage source and class files, although The Java Language Specification does not require this. The strategy is as follows.
Put the source code for a class, interface, enumeration, or annotation type in a text file whose name is the simple name of the type and whose extension is .java
. For example:
//in the Rectangle.java file package graphics; public class Rectangle { ... }
Then, put the source file in a directory whose name reflects the name of the package to which the type belongs:
.....\graphics\Rectangle.java
The qualified name of the package member and the path name to the file are parallel, assuming the Microsoft Windows file name separator backslash (for UNIX, use the forward slash).
graphics.Rectangle
graphics\Rectangle.java
As you should recall, by convention a company uses its reversed Internet domain name for its package names. The Example company, whose Internet domain name is example.com
, would precede all its package names with com.example
. Each component of the package name corresponds to a subdirectory. So, if the Example company had a com.example.graphics
package that contained a Rectangle.java
source file, it would be contained in a series of subdirectories like this:
....\com\example\graphics\Rectangle.java
When you compile a source file, the compiler creates a different output file for each type defined in it. The base name of the output file is the name of the type, and its extension is .class
. For example, if the source file is like this
//in the Rectangle.java file package com.example.graphics; public class Rectangle { . . . } class Helper{ . . . }
then the compiled files will be located at:
<path to the parent directory of the output files>\com\example\graphics\Rectangle.class <path to the parent directory of the output files>\com\example\graphics\Helper.class
Like the .java
source files, the compiled .class
files should be in a series of directories that reflect the package name. However, the path to the .class
files does not have to be the same as the path to the .java
source files. You can arrange your source and class directories separately, as:
<path_one>\sources\com\example\graphics\Rectangle.java <path_two>\classes\com\example\graphics\Rectangle.class
By doing this, you can give the classes
directory to other programmers without revealing your sources. You also need to manage source and class files in this manner so that the compiler and the Java Virtual Machine (JVM) can find all the types your program uses.
The full path to the classes
directory, <path_two>\classes
, is called the class path, and is set with the CLASSPATH
system variable. Both the compiler and the JVM construct the path to your .class
files by adding the package name to the class path. For example, if
<path_two>\classes
is your class path, and the package name is
com.example.graphics,
then the compiler and JVM look for .class files
in
<path_two>\classes\com\example\graphics.
A class path may include several paths, separated by a semicolon (Windows) or colon (UNIX). By default, the compiler and the JVM search the current directory and the JAR file containing the Java platform classes so that these directories are automatically in your class path.
To display the current CLASSPATH
variable, use these commands in Windows and UNIX (Bourne shell):
In Windows: C:\> set CLASSPATH In UNIX: % echo $CLASSPATH
To delete the current contents of the CLASSPATH
variable, use these commands:
In Windows: C:\> set CLASSPATH= In UNIX: % unset CLASSPATH; export CLASSPATH
To set the CLASSPATH
variable, use these commands (for example):
In Windows: C:\> set CLASSPATH=C:\users\george\java\classes In UNIX: % CLASSPATH=/home/george/java/classes; export CLASSPATH