SCOUG Logo


Next Meeting: Sat, Nov 16, 2019
Meeting Directions


Be a Member
Join SCOUG

Navigation:


Help with Searching

20 Most Recent Documents
Search Archives
Index by date, title, author, category.


Features:

Mr. Know-It-All
Ink
Download!




SCOUG:

Home

Email Lists

SIGs (Internet, General Interest, Programming, Network, more..)

Online Chats

Business

Past Presentations

Credits

Submissions

Contact SCOUG

Copyright SCOUG



warp expowest
Pictures from Sept. 1999


The views expressed in articles on this site are those of their authors.

warptech
SCOUG was there!


Copyright 2019, Southern California OS/2 User Group. ALL RIGHTS RESERVED.

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.

The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA

SCOUG OS/2 For You - October 1999


Cup of Java

A Class by Any Other Name

by Terry Warren

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:

package package1; public class TestClass ... { ... } then the file TestClass.java needs to be in a subdirectory named package1 off of the path from which you are compiling. So, the command line for compiling would be: javac package1\TestClass.java If the source file defines the class package1.sub2.AnotherClass then AnotherClass.java must be in the subdirectory package\sub2 off of the path from which you are compiling.

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

set classpath=...;d:\zips\object.zip;... and the Java runtime would load the classes correctly. For this to work you must be sure to preserve the directory structure of the files in the zip.

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:

jre -cp d:\zips\object.zip ... This distinction does not exist in Java 1.2 since the JRE executables no longer exist.

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:


The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA

Copyright 1999 the Southern California OS/2 User Group. ALL RIGHTS RESERVED.

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.