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()
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. This filename
is interpreted relative to the Java "class path," described below.
We'll use UNIX-style directory specifications in this book. 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.
Packages of the Java API
Table 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 |
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:
setenv 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 overides 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.
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.
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 doesn't 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.
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 in the next chapter.
A package is accessible if the appropriate files and directories are
accessible (e.g., if local files have appropriate read permissions, or
if they can be downloaded via the network).
All classes and interfaces in a package are accessible to all other
classes and interfaces in the same package. It is not possible to
define classes in Java that are visible only within a single file of
source code.
A class declared public in one package is accessible within another
package, assuming that the package itself is accessible. A non-public
class is not accessible outside of its package.
Members of a class are accessible from a different class within the
same package, as long as they are not declared private. private members
are accessible only within their own class.
Af member of a class A is accessible from a class B in a different
package if A is public and the member is public, or if A is public, the
member is protected, and B is a subclass of A.
All members of a class are always accessible from within that class.
Local Variables
The name space rules we've 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 C--they 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.
Comments
Java supports three types of comments:
A standard C-style comment that begins with /* and continues until the
next */. As in most implementations of C, this style of comment cannot
be nested.
A C++-style comment that begins with // and continues until the end of the line.
A special "doc comment" that begins with /** and continues until the
next */. These comments may not be nested. Doc comments are specially
processed by the javadoc program to produce simple online documentation
from the Java source code.