Previous Table of Contents Next


14.2.2. The Name Space: Packages, Classes, and Members

As a language that is designed to support dynamic loading of modules over the entire Internet, Java takes special care to avoid name space conflicts. Global variables are simply not part of the language. Neither are “global” functions or procedures, for that matter.

14.2.2.1. No Global Variables

In Java, every field and method is declared within a class and forms part of that class. Also, every class is part of a package (in Java 1.1, classes can also be declared within other classes). The fields and methods (and classes in 1.1) of a class are known as the members of a class. Every Java field or method may be referred to by its fully qualified name, which consists of the package name, the class name, and the member name (i.e., the field or the method name), all separated by periods. Package names are themselves usually composed of multiple period-separated components. Thus, the fully qualified name for a method might be:

   david.games.tetris.SoundEffects.play()

14.2.2.2. Java Filenames and Directory Structure

A file of Java source code has the extension .java. It consists of an optional package statement followed by any number of import statements followed by one or more class or interface definitions. (The package and import statements will be introduced shortly.) If more than one class or interface is defined in a Java source file, only one of them may be declared public (i.e., made available outside of the package), and the source file must have the same name as that public class or interface, plus the .java extension.

Each class or interface definition in a .java file is compiled into a separate file. These files of compiled Java byte-codes are known as “class files,” and must have the same name as the class or interface they define, with the extension .class appended. For example, the class SoundEffects would be stored in the file SoundEffects.class.

Class files are stored in a directory that has the same components as the package name. If the fully qualified name of a class is david.games.tetris.SoundEffects, for example, the full path of the class file must be david/games/tetris/SoundEffects.class.5 This filename is interpreted relative to the Java “class path,” described below.


5We’ll use UNIX-style directory specifications in this chapter. If you are a Windows programmer, simply change all the forward slashes in filenames to backward slashes. Similarly, in path specifications, change colons to semicolons.

14.2.2.3. Packages of the Java API

The Java 1.1 API consists of the classes and interfaces defined in the twenty-three packages listed in Table 14.1.

TABLE 14.1. The packages of the Java API.

Package Name Contents

java.applet Applet classes
java.awt Graphics, window, and GUI classes
java.awt.datatransfer Data transfer (e.g., cut-and-paste) classes
java.awt.event Event processing classes and interfaces
java.awt.image Image processing classes
java.awt.peer GUI interfaces for platform independence
java.beans JavaBeans component model API
java.io Various types of input and output classes
java.lang Core language classes
java.lang.reflect Reflection API classes
java.math Arbitrary precision arithmetic
java.net Networking classes
java.rmi Remote Method Invocation classes
java.rmi.dgc RMI-related classes
java.rmi.registry RMI-related classes
java.rmi.server RMI-related classes
java.security Security classes
java.security.acl Security-related classes
java.security.interfaces Security-related classes
java.sql JDBC SQL API for database access
java.text Internationalization classes
java.util Various useful data types
java.util.zip Compression and decompression classes

14.2.2.4. The Java Class Path

The Java interpreter knows where its standard system classes are installed, and loads them from that location as needed. By default, it looks up user-defined classes in or relative to the current directory. You can set the CLASSPATH environment variable to tell the interpreter where to look for user-defined classes. The interpreter always appends the location of its system classes to the end of the path specified by this environment variable. The entries in a class path specification should be directories or ZIP files that contain the classes. The directories in a class path specification should be colon-separated on a UNIX system, and semicolon-separated on a Windows system. For example, on a UNIX system, you might use:

   setenv CLASSPATH .:/home/david/classes:
        /usr/local/javatools/classes.zip

On a Windows system you could use:

   set CLASSPATH .;C:\^\david\classes;D:\local\javatools\classes.zip

This tells Java to search in and beneath the specified directories for non-system classes. Note that the current directory (.) is included in these paths.

You can also specify a class path to the Java interpreter with the -classpath command-line argument . Setting this option overrides any path specified in the CLASSPATH environment variable. Note that the interpreter does not append the location of the system classes to the end of this path, so you must be sure to specify those system classes yourself. Finally, note that the Java compiler also recognizes and honors class paths specified with the CLASSPATH environment variable and the -classpath command-line argument.


Previous Table of Contents Next