For the Java beginner, it is often confusing to understand Java class naming conventions, especially in relation to how the compiler and runtime environments locate classes when needed. In this article we will look at the rules and restrictions governing names.

Class Names

The basic rules for naming Java classes and files are:

1. A Java source file must have the same name as the public class (or interface) that is defined within it. The file must be given the file extension .java and may contain only one public class (or interface) definition (although it may contain additional non-public definitions). So, for example, if your source code contains the following definition: publc class MyClass extends ... { ... } then the file must be named: MyClass.java

   It is important to note that all names in Java are case sensitive (including directory and subdirectory names).

2. When a .java file is compiled, the compiled bytecode will be put into a file with the same name as the public class (or interface) being defined and will have the .class file extension. In the previous example, if MyClass.java is compiled, the output file would be: MyClass.class

3. If the .java file contains additional non-public classes (or nested classes), each such class will be compiled into a separate .class file with the appropriate name. For example, if the MyClass.java file contained the following definitions: public class MyClass ... { ... } private class ClassTwo ... { ... } private class ClassThree ... { ... } then three .class files would be created during the compilation of MyClass.java.

4. By default, the .class files resulting from the compilation will be created into the same directory as the .java file. However, the -d compiler switch can be used to change the destination of the output files. So, if you entered the command line: javac MyClass.java the file MyClass.class would end up in the same directory; but, if you entered: javac -d c:\object MyClass.java MyClass.class would be written into the object directory of the c: drive.

5. If the source file being compiled is part of a Java package, then it must exist in a subdirectory structure that represents the full package name and this structure must exist below the current directory (or subdirectory) from which the compile is invoked.

This may seem complicated, so let's look at a couple of examples: If the source file defines the class package1.TestClass:

Finding Classes at Runtime

From the previous discussion, you can see that, after compiling a number of classes and packages, you will end up with a set of directories and subdirectories (reflecting the package names) and .class files within those directories for the different classes in your application. So, when you execute the application and references to classes are encountered, how does the Java runtime environment know how to resolve these references?

The answer is that an environment variable, classpath, is used to perform this resolution. This variable contains a list of directories, separated by ; which define where .class files can be found. If the current directory is to be included, it must be explicitly defined in this list as .; or .\; (otherwise it won't be used). Note that packages will be searched for relative to these directory names so it is not necessary to explicitly include subdirectories. For example, if the classes defined above (MyClass, package1.TestClass, package1.sub2.AnotherClass) were all located from the directory d:\object then only d:\object need be specified in the classpath variable OR, if you are executing from d:\object, then you only need to include .; in classpath.

One of the nice features of Java is that it can also load classes from compressed files such as .zip files or .jar files. So, if you created object.zip which contained MyClass.class, package1\TestClass.class and package1\sub2\AnotherClass.class then you could include that zipfile in classpath (giving its full path location), such as

A final note on loading classes: in Java 1.1.x there are two different methods for executing applications: using the JDK and using the JRE. In most cases you would use the JRE and it has an added capability for defining location of classes. There is a commandline switch -cp which allows you to specify an additional list of directories to use in the search; these directories are used before the list in classpath. So, for example, if you wanted to include the zipfile desribed above but didn't want to alter the classpath variable, you could invoke the Java runtime as follows:

Summary

Java has a number of rules for naming source files, packages and class files but also provides convenient mechanisms for managing these files both at compile time and at execution time.

In the next article, we will look at the class loading process itself in more detail, including ways to circumvent hacking of the class files.

Cup of Java by Terry Warren is a series that started in April 1999. Prior articles are:

• Threads and Java
• Event Handling
• Zipping Along
• Exceptions Are the Rule

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group.
OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation.
All other trademarks remain the property of their respective owners.