Previous | Table of Contents | Next |
14.2.2.5. Globally Unique Package Names
The Java designers have proposed an Internet-wide unique package naming scheme that is based on the Internet domain name of the organization at which the package is developed.
Figure 14.2 shows some fully qualified names, which include package, class, and field components.
FIGURE 14.2. Fully qualified names in Java.
Some organizations are following this naming scheme, and producing classes with names like com.sybase.jdbc.SybDriver. Another trend that is developing, however, is for companies to simply use their company name as the first component of their package names, and produce classes like netscape.javascript.JSObject.
The top-level package names java and sun are reserved for use by Sun, of course. Developers should not define new classes within these packages.
14.2.2.6. The package Statement
The package statement must appear as the first statement (i.e., the first text other than comments and whitespace) in a file of Java source code, if it appears at all. It specifies which package the code in the file is part of. Java code that is part of a particular package has access to all classes (public and non-public) in the package, and to all non-private methods and fields in all those classes. When Java code is part of a named package, the compiled class file must be placed at the appropriate position in the CLASSPATH directory hierarchy before it can be accessed by the Java interpreter or other utilities.
If the package statement is omitted from a file, the code in that file is part of an unnamed default package. This is convenient for small test programs, or during development, because it means that the code can be interpreted from the current directory.
14.2.2.7. The import Statement
The import statement makes Java classes available to the current class under an abbreviated name. Public Java classes are always available by their fully qualified names, assuming that the appropriate class file can be found (and is readable) relative to the CLASSPATH environment variable. import doesnt actually make the class available or read it in; it simply saves you typing and makes your code more legible.
Any number of import statements may appear in a Java program. They must appear, however, after the optional package statement at the top of the file, and before the first class or interface definition in the file.
There are two forms of the import statement:
import package.class ; import package.* ;
The first form allows the specified class in the specified package to be known by its class name alone. Thus, this import statement allows you to type Hashtable instead of java.util.Hashtable:
import java.util.Hashtable;
The second form of the import statement makes all classes in a package available by their class name. For example, the following import statement is implicit (you need not specify it yourself) in every Java program:
import java.lang.*;
It makes the core classes of the language available by their unqualified class names. If two packages imported with this form of the statement contain classes with the same name, it is an error to use either of those ambiguous classes without using its fully qualified name.
14.2.2.8. Access to Packages, Classes, and Class Members
Java has the following rules about access to packages, classes, and class members. (Class members are the variables, methods, and, in Java 1.1, nested classes defined within a class.) Note that the public, private, and protected keywords used in these rules will be explained in more detail later.
14.2.2.9. Local Variables
The name space rules weve been describing apply to packages, classes, and the members within classes. Java also supports local variables, declared within method definitions. These local variables behave just like local variables in Cthey do not have globally unique hierarchical names, nor do they have access modifiers like public and private. Local variables are quite different from class fields.
Java supports three types of comments:
Since C-style comments do not nest, it is a good idea to use C++-style // comments for most of your short comments within method bodies. This allows you to use /* */ comments to comment out large blocks of code when you need to do that during development. This is especially important because, as you will see, Java does not support a preprocessor that allows you to use #if 0 to comment out a block.
Previous | Table of Contents | Next |