Lesson 9.6 Packages
Creating Packages
Packages are a group of classes that have a special relationship to each other. For instance, all of the user-interface classes are contained in the package java.awt.*. Classes that are in the same package are said to be "friendly" and can access the non-private fields of other classes in the same package.
In this lesson you'll revisit access specifiers where you'll learn about package scope. Then, you'll learn how to create packages of your own.
Scope and Access
In this lesson, you learned about access specifiers. Access specifiers are used to control which fields and methods can be accessed by which objects.
Java has four different access specifiers: public, private, package, and protected. We'll look at the first three in this section, and save the last for the next lesson.
Private Access
The most restrictive of the access specifiers is private. If a variable [or a method] is declared private, then it can only be accessed by methods in that class.
|
Within What Class?
|
| What "within that class" means is not always exactly clear, even for those who create your compilers and JVMs. If, for instance, you create a private field in one of your classes, should that field be accessible from an inner class in the same class? Currently Sun's implementation allows this, and Microsoft's JVM does not. |
It is important that you understand that privacy is enforced on a class-by-class basis, and not an object-by-object basis. Here's an example.
Suppose you have the following class:
class Busy
{
private int value;
public exchange(Busy b)
{
int temp = value;
value = b.value;
b.value = temp;
}
} |
What happens if you create two Busy objects like this:
Busy one = new Busy(1);
Busy two = new Busy(2); |
And then call the exchange() method like this:
You might think that because the int field value was declared private that the object one would not be able to "mess with" object two's copy of value. But that's not the case. If two objects belong to the same class, then one object can directly access the private variables of another object.
Public Access
The least restrictive of the access specifiers is public. If a method has public in front of it, then any object of that class can be told to perform that action. If a method is declared private, even if you have a particular object, you can't tell it to perform its private actions, unless "you" are a member of the same class.
Fields that are public are very similar. If a class has a public field, then any other method, provided it has an instance of that class [an object], can directly read the field's value or, provided that it is not marked final, can change the field's value.
This is generally not a good idea for several reasons. Except for small "utility" classes that are used to bundle up multiple pieces of information your classes should not use public, non-final fields.
One widely accepted use of public however, is to provide class constants that are helpful when constructing objects of the class. Such fields are declared static final, and make it easier to remember a particular argument. Examples that you're familiar with are the Font.BOLD field and the Label.LEFT field.
Package Access
The third access specifier, package, is what you get if you don't put public, private, or protected in front of your fields or methods. Although package is a keyword, it is not used to specify package access.
With package access, every class that is in the same package has access to the fields and methods in your class. "In the same package", however, has two different definitions.
- A class may be explicitly placed in a package by use of the package keyword, which you'll see later in this lesson.
- A class may also be implicitly placed in the "unnamed" package. The unnamed package includes all classes in the current directory. The result of this is, if you fail to put private in front of your fields, then every class in the same directory can directly access the fields in your class.
For some unknown reason, Sun decided to make package access the default. In other OO languages, private access is the default, even when there is a public scope. To protect yourself, you should always use private when declaring your fields.
Using Packages
Packages are not "bundles" of classes; those are called JAR or Java ARchive files. You'll learn how to create archive files that can bundle multiple classes into a single package in a later lesson.
Instead, packages are groups of related classes that are placed in the same directory for convenience. All the classes in a particular package are stored using a standard "placement", which is easier to show by example than to explain.
Let's look at a package you're already familiar with: java.awt.event. All the classes in the java.awt.event package are located:
- in a subdirectory called event,
- which is contained in a subdirectory called awt,
- which is contained in a subdirectory called java.
CLASSPATH
The directory java--the first-level directory in this example--can be located anywhere on your computer, provided the name of the directory is contained in the CLASSPATH environmental variable.
The CLASSPATH variable contains a separated list of directories and/or archive files. In versions of the JDK prior to 1.1.6, you were responsible for making sure that the CLASSPATH included both the current directory [the unnamed package] and the Java system files, which are archived in a file called classes.zip in your JDK lib directory.
Current versions of the JDK include these two directories in the CLASSPATH automatically, but you are still responsible for correctly setting it to refer to any other libraries you may use.
Creating a Package
Let's assume you want to create a package called mycomponents to store the various components you create during the course.
Let's start by placing your Spinner component [from the homework assignment for this lesson] in the mycomponents package.
Here are the steps to follow:
1. Add package mycomponents; to top of the Spinner.java file. This statement must be the first non-comment statement in the file, appearing before, even, your import statements.
2. Create a subdirectory called mycomponents underneath your current directory, and copy the Spinner.class file, [compiled after package mycomponents was added], to the subdirectory.
3. Place your applet that uses Spinner in the directory that contains the mycomponents subdirectory.
4. Add import mycomponents.*; to the top of your applet.
In JDK 1.1, you can add the directory that contains the mycomponents subdirectory to your CLASSPATH, and your applets that use the Spinner class can be located anywhere.
In Java 2 this behavior has been changed, and packages used by a particular applet must appear below the directory where the applet's class files are located. Applets no longer use the CLASSPATH variable.
Something to Talk About
The new Java 2 user interface classes, called the Swing components, are in the javax.swing package. Where would those classes be physically installed on your computer? [Don't worry about .jar files or .zip files. Assume that the system classes are present just like any other package.]
This is the last section of this lesson.
|
