WebReference.com - Part 4 of chapter 5 from Beginning Java 2 SDK 1.4 Edition, Wrox Press Ltd (1/8) | WebReference

WebReference.com - Part 4 of chapter 5 from Beginning Java 2 SDK 1.4 Edition, Wrox Press Ltd (1/8)

current pageTo page 2To page 3To page 4To page 5To page 6To page 7To page 8
[next]

Beginning Java 2 SDK 1.4 Edition

Understanding Packages

[The following is a continuation of our series of excerpts from chapter 5 of the Wrox Press title, Beginning Java 2 SDK 1.4 Edition. Source code for the examples discussed can be downloaded at the Wrox Web site (free e-mail registration required).]

Packages are fundamental to Java programs so make sure you understand this section.

Packages are implicit in the organization of the standard classes as well as your own programs, and they influence the names you can use for classes and the variables and methods they contain. Essentially, a package is a unique named collection of classes. The purpose of grouping classes in a package with a unique name is to make it easy to add any or all of the classes in a package into your program code. One aspect of this is that the names used for classes in one package will not interfere with the names of classes in another package, or your program, because the class names in a package are qualified by the package name.

Every class in Java is contained in a package, including all those we have defined in our examples. You haven't seen many references to package names so far because we have been implicitly using the default package to hold our classes, and this doesn't have a name.

All of the standard classes in Java are contained within packages. The package that contains most of the standard classes that we have used so far is called java.lang. You haven't seen any explicit reference to this in your code either, because this package is automatically available to your programs. Things are arranged this way because some of the classes in java.lang, such as String, are used in every program. There are other packages containing standard classes that you will need to include explicitly when you use them, as we did in the previous chapter with the StringTokenizer class.

Packaging Up Your Classes

Putting one of your classes in a package is very simple. You just add a package statement as the first statement in the source file containing the class definition. Note that it must always be the first statement. Only comments or blank lines are allowed to precede the package statement. A package statement consists of the keyword, package, followed by the package name, and is terminated by a semi-colon. If you want the classes in a package to be accessible outside the package, you must declare the class using the keyword public in the first line of your class definition. Class definitions that aren't preceded by the keyword public are only accessible from methods in classes that belong to the same package.

For example, to include the class Sphere in a package called Geometry, the contents of the file Sphere.java would need to be:

package Geometry;
public class Sphere {
  // Details of the class definition
}

Each class that you want to include in the package Geometry must contain the same package statement at the beginning, and you should save all the files for the classes in the package in a directory with the same name as the package, that is, Geometry. Note the use of the public keyword in the definition of the Sphere class. This is to make the class usable generally.

Note that you would also need to declare the constructors and methods in the class as public if you want them to be accessible from outside of the package. We will return to this in more detail a little later in this chapter.

Packages and the Directory Structure

Packages are actually a little more complicated than they appear at first sight, because a package is intimately related to the directory structure in which it is stored. You already know that the definition of a class with the name ClassName must be stored in a file with the name ClassName.java, and that all the files for classes within a package, PackageName, must be included in a directory with the name PackageName. You can compile the source for a class within a package and have the .class file that is generated stored in a different directory, but the directory name must still be the same as the package name.

A package need not have a single name. You can specify a package name as a sequence of names separated by periods. For example, you might have developed several collections of classes dealing with geometry, one dealing with 2D shapes and another with 3D shapes. In this case you might include the class Sphere in a package with the statement:

package Geometry.Shapes3D;

and the class for circles in a package using the statement:

package Geometry.Shapes2D;

In this situation, the packages are expected to be in the directories Shapes3D and Shapes2D, and both of these must be sub-directories of Geometry. In general, you can have as many names as you like separated by periods to identify a package, but the name must reflect the directory structure where the package is stored.

The relationship of Java Packages to Directory Structure


current pageTo page 2To page 3To page 4To page 5To page 6To page 7To page 8
[next]

Created: July 29, 2002
Revised: July 29, 2002


URL: http://webreference.com/programming/java/beginning/chap5/4/