Scribd
Upload
4 views

java_research_8

Chapter 9 discusses Java's features of packages and interfaces, which help manage class name spaces and allow for method abstraction. Packages serve as containers for classes to prevent name collisions and control visibility, while interfaces enable multiple classes to implement a set of methods without defining their implementation. The chapter also explains how to create packages, the importance of directory structure, and how to set the CLASSPATH for the Java runtime system to locate packages.

Uploaded by

Asim Dinda
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
4 views

java_research_8

Chapter 9 discusses Java's features of packages and interfaces, which help manage class name spaces and allow for method abstraction. Packages serve as containers for classes to prevent name collisions and control visibility, while interfaces enable multiple classes to implement a set of methods without defining their implementation. The chapter also explains how to create packages, the importance of directory structure, and how to set the CLASSPATH for the Java runtime system to locate packages.

Uploaded by

Asim Dinda
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 5

CHAPTER 9

Packages and Interfaces

This chapter examines two of Java’s most innovative features: packages


and interfaces. Packages are containers for classes. They are used to keep
the class name space compartmentalized. For example, a package allows
you to create a class named List, which you can store in your own package
without concern that it will collide with some other class named List
stored elsewhere. Packages are stored in a hierarchical manner and are
explicitly imported into new class definitions. As you will see in Chapter
16, packages also play an important role with modules.
In previous chapters, you have seen how methods define the interface to
the data in a class. Through the use of the interface keyword, Java allows
you to fully abstract an interface from its implementation. Using
interface, you can specify a set of methods that can be implemented by
one or more classes. In its traditional form, the interface, itself, does not
actually define any implementation. Although they are similar to abstract
classes, interfaces have an additional capability: A class can implement
more than one interface. By contrast, a class can only inherit a single
superclass (abstract or otherwise).

Packages
In the preceding chapters, the name of each example class was taken from
the same name space. This means that a unique name had to be used for
each class to avoid name collisions. After a while, without some way to
manage the name space, you could run out of convenient, descriptive
names for individual classes. You also need some way to be assured that
the name you choose for a class will be reasonably unique and not collide
with class names chosen by other programmers. (Imagine a small group of
programmers fighting over who gets to use the name “Foobar” as a class
name. Or, imagine the entire Internet community arguing over who first
named a class “Espresso.”) Thankfully, Java provides a mechanism for
partitioning the class name space into more manageable chunks. This
mechanism is the package. The package is both a naming and a visibility
control mechanism. You can define classes inside a package that are not
accessible by code outside that package. You can also define class
members that are exposed only to other members of the same package.
This allows your classes to have intimate knowledge of each other, but not
expose that knowledge to the rest of the world.

Defining a Package
To create a package is quite easy: simply include a package command as
the first statement in a Java source file. Any classes declared within that
file will belong to the specified package. The package statement defines a
name space in which classes are stored. If you omit the package
statement, the class names are put into the default package, which has no
name. (This is why you haven’t had to worry about packages before now.)
While the default package is fine for short, sample programs, it is
inadequate for real applications. Most of the time, you will define a
package for your code.
This is the general form of the package statement:
package pkg;
Here, pkg is the name of the package. For example, the following
statement creates a package called mypackage:
package mypackage;

Typically, Java uses file system directories to store packages, and that is
the approach assumed by the examples in this book. For example, the
.class files for any classes you declare to be part of mypackage must be
stored in a directory called mypackage. Remember that case is
significant, and the directory name must match the package name exactly.
More than one file can include the same package statement. The
package statement simply specifies to which package the classes defined
in a file belong. It does not exclude other classes in other files from being
part of that same package. Most real-world packages are spread across
many files.
You can create a hierarchy of packages. To do so, simply separate each
package name from the one above it by use of a period. The general form
of a multileveled package statement is shown here:
package pkg1[.pkg2[.pkg3]];
A package hierarchy must be reflected in the file system of your Java
development system. For example, a package declared as
package a.b.c;

needs to be stored in a\b\c in a Windows environment. Be sure to choose


your package names carefully. You cannot rename a package without
renaming the directory in which the classes are stored.

Finding Packages and CLASSPATH


As just explained, packages are typically mirrored by directories. This
raises an important question: How does the Java run-time system know
where to look for packages that you create? As it relates to the examples in
this chapter, the answer has three parts. First, by default, the Java run-time
system uses the current working directory as its starting point. Thus, if
your package is in a subdirectory of the current directory, it will be found.
Second, you can specify a directory path or paths by setting the
CLASSPATH environmental variable. Third, you can use the -classpath
option with java and javac to specify the path to your classes. It is useful
to point out that, beginning with JDK 9, a package can be part of a module,
and thus found on the module path. However, a discussion of modules and
module paths is deferred until Chapter 16. For now, we will use only class
paths.
For example, consider the following package specification:
package mypack;
In order for a program to find mypack, the program can be executed from
a directory immediately above mypack, or the CLASSPATH must be set
to include the path to mypack, or the -classpath option must specify the
path to mypack when the program is run via java.
When the second two options are used, the class path must not include
mypack, itself. It must simply specify the path to mypack. For example,
in a Windows environment, if the path to mypack is
C:\MyPrograms\Java\mypack

then the class path to mypack is


C:\MyPrograms\Java

The easiest way to try the examples shown in this book is to simply
create the package directories below your current development directory,
put the .class files into the appropriate directories, and then execute the
programs from the development directory. This is the approach used in the
following example.

A Short Package Example


Keeping the preceding discussion in mind, you can try this simple
package:
Call this file AccountBalance.java and put it in a directory called
mypack.
Next, compile the file. Make sure that the resulting .class file is also in
the mypack directory. Then, try executing the AccountBalance class,
using the following command line:
java mypack.AccountBalance

Remember, you will need to be in the directory above mypack when you
execute this command. (Alternatively, you can use one of the other two

You might also like