

Section 4.6

APIs, Packages, Modules, and Javadoc


4.6.1  Toolboxes

Someone who wanted to program for the original Macintosh computers—and to produce programs that look and behave the way users expected them to—had to deal with the "Macintosh Toolbox," a collection of well over a thousand different subroutines. There were routines for opening and closing windows, for drawing geometric figures and text to windows, for adding buttons to windows, and for responding to mouse clicks on the window. There were other routines for creating menus and for reacting to user selections from menus. Aside from the user interface, there were routines for opening files and reading data from them, for communicating over a network, for sending output to a printer, for handling communication between programs, and in general for doing all the standard things that a computer has to do. Microsoft Windows provides its own set of subroutines for programmers to use, and they are quite a bit different from the subroutines used on the Mac. Linux has several different GUI toolboxes for the programmer to choose from.


A software toolbox is a kind of black box, and it presents a certain interface to the programmer. This interface is a specification of what routines are in the toolbox, what parameters they use, and what tasks they perform. This information constitutes the API, or Application Programming Interface, associated with the toolbox. The Macintosh API is a specification of all the routines available in the Macintosh Toolbox. A company that makes some hardware device—say a card for connecting a computer to a network—might publish an API for that device consisting of a list of routines that programmers can call in order to communicate with and control the device. Scientists who write a set of routines for doing some kind of complex computation—such as solving "differential equations," say—would provide an API to allow others to use those routines without understanding the details of the computations they perform.



4.6.2  Java's Standard Packages

Like all subroutines in Java, the routines in the standard API are grouped into classes. To provide larger-scale organization, classes in Java can be grouped into packages, which were introduced briefly in Subsection 2.6.7. You can have even higher levels of grouping, since packages can also contain other packages. In fact, the entire standard Java API is implemented in several packages. One of these, which is named "java", contains several non-GUI packages as well as the original AWT graphical user interface classes. Another package, "javax", contains the classes used by the Swing graphical user interface as well as many other classes. And "javafx" contains the JavaFX API that is used for GUI programming in this textbook.

A package can contain both classes and other packages. A package that is contained in another package is sometimes called a "sub-package." Both the java package and the javafx package contain sub-packages. One of the sub-packages of java, for example, is named "util". Since util is contained within java, its full name is actually java.util. This package contains a variety of utility classes, including the Scanner class that was discussed in Subsection 2.4.6. The java package includes several other sub-packages, such as java.io, which provides facilities for input/output, and java.net, which deals with network communication. The most basic package is called java.lang. This package contains fundamental classes such as String, Math, Integer, and Double.


(Diagram of subroutine/class/package nesting)

Similarly, the package javafx contains a package javafx.scene, which in turn contains javafx.scene.control. This package contains classes that represent GUI components such as buttons and input boxes. Another subpackage, javafx.scene.paint, contains class Color and other classes that define ways to fill and stroke a shape.

The standard Java API includes thousands of classes in hundreds of packages. Many of the classes are rather obscure or very specialized, but you might want to browse through the documentation to see what is available. As I write this, the documentation for the complete basic API for Java 8 can be found at


and for JavaFX at


See the subsection about "modules," below, for a discussion of changes that were made the language in Java 9 and for links to the documentation for Java 11. However, for the purposes of this textbook, you will probably find that the Java 8 documentation is easier to use.

Even an expert programmer won't be familiar with the entire Java API, or even a majority of it. In this book, you'll only encounter several dozen classes, and those will be sufficient for writing a wide variety of programs.

4.6.3  Using Classes from Packages

Let's say that you want to use the class javafx.scene.paint.Color in a program that you are writing. This is the full name of class Color in package javafx.scene.paint. Like any class, javafx.scene.paint.Color is a type, which means that you can use it to declare variables and parameters and to specify the return type of a function. One way to do this is to use the full name of the class as the name of the type. For example, suppose that you want to declare a variable named rectColor of type Color. You could say:

javafx.scene.paint.Color  rectColor;

This is just an ordinary variable declaration of the form "type-name variable-name;". Of course, using the full name of every class can get tiresome, and you will hardly ever see full names like this used in a program. Java makes it possible to avoid using the full name of a class by importing the class. If you put

import javafx.scene.paint.Color;

at the beginning of a Java source code file, then, in the rest of the file, you can abbreviate the full name javafx.scene.paint.Color to just the simple name of the class, which is Color. Note that the import line comes at the start of a file (after the package statement, if there is one) and is not inside any class. Although it is sometimes referred to as a statement, it is more properly called an import directive since it is not a statement in the usual sense. The import directive "import javafx.scene.paint.Color" would allow you to say

Color  rectColor;

to declare the variable. Note that the only effect of the import directive is to allow you to use simple class names instead of full "package.class" names. You aren't really importing anything substantial; if you leave out the import directive, you can still access the class—you just have to use its full name. There is a shortcut for importing all the classes from a given package. For example, you can import all the classes from java.util by saying

import java.util.*;

The "*" is a wildcard that matches every class in the package. (However, it does not match sub-packages; for example, you cannot import the entire contents of all the sub-packages of the javafx package by saying import javafx.*.)




Programmers can create new packages. Suppose that you want some classes that you are writing to be in a package named utilities. Then the source code files that defines those classes must begin with the line

package utilities;



However, with just a couple of exceptions such as class TextIO in package textio, the classes written for this book are not in packages. For the purposes of this book, you need to know about packages mainly so that you will be able to import TextIO and classes from the standard packages. The standard packages are always available to the programs that you write. You might wonder where the standard classes are actually located. Again, that can depend to some extent on the version of Java that you are using. In Java 8 they are stored in jar files in a subdirectory named lib inside the Java Runtime Environment installation directory. A .jar (or "Java archive") file is a single file that can contain many classes. Most of the classes used with Java 8 can be found in a jar file named rt.jar. Things changed substantially in Java 9, as discussed in the next subsection.


4.6.4  About Modules

Starting with Java 9, a major change was made to the large-scale structure of Java with the introduction of modules. A module is a collection of packages, so it represents yet another level of containment: Modules contain packages which contain classes which contain variables and methods. A package does not have to be in a module to be used, but all of the standard classes in Java and in JavaFX have been divided into a set of modules.

Modules were introduced for several reasons. A major reason is to provide better access control. Before modules, a class that is declared public can be used anywhere, from any class in any package, as can its public variables and methods. For a class that is defined in a module, on the other hand, "public" only automatically means public within the module where it is defined. However, a module can explicitly export a package. Exporting a package from a module makes the public classes in the package accessible from anywhere, including from other modules and from classes that are not part of any module. (It is even possible to export a package just to certain specified modules, providing an even finer level of access control.) The upshot is that it is now possible to have entire packages that are essentially private: They provide services to other packages in the same module, but are invisible from outside that module. So a module is another kind of black box, and a non-exported package is part of its hidden implementation. Of course, modularity on this scale is really only important for very large-scale applications.

Another motivation for modules is the sheer size of the standard JRE (Java Runtime Environment), which includes all of the standard classes. A given application will use only a small part of the standard runtime. Modularization makes it possible to construct smaller, custom JREs that contain only the modules that are required by an application. The JDK includes a jlink command for making custom runtimes, which can include modules that define an application as well as the standard modules that are required to run that application. That runtime can then be distributed as a standalone application that can be executed even by people who have not installed a JDK on their computer. But just as for the JDK itself, different versions of the custom runtime will be needed for Windows, for Mac OS, and for Linux. Furthermore, when security updates are made to the JDK, they are not automatically applied to custom runtimes, so the application developer takes on the responsibility of updating custom runtimes. Once again, this is really only useful for fairly large applications.

In a JDK for Java 9 or later, compiled class files from the standard modules are stored together in a file named modules inside a directory named lib in the main JDK directory. This is a so-called "jimage file," and there is a command-line tool named jimage for working with such files. If you use the jlink tool to create a custom runtime, part of what it does is to create a custom modules file containing just the modules that are needed by the runtime. In the JDK 12 on my Linux computer, modules is a 130 megabyte file containing 30199 classes in 1000 packages in 70 modules. The JDK directory also has a subdirectory named jmods that contains the modules in another form. However, it is not required for compiling and running programs and, as far as I can tell, is meant mostly for use by jlink.

Modules in the JDK include, for example, java.base (which contains the basic modules such as java.lang and java.util) and java.desktop (which include packages for the Swing GUI toolkit). JavaFX packages include javafx.base, javafx.control, javafx.graphics, and a few that are less generally useful. The API documentation for modular versions of Java is divided into modules, then into packages, and finally into classes. This makes the documentation harder to browse than in older versions of Java. However, the documentation web site does have an effective search feature. As I write this, the documentation for Java 11 and for JavaFX 11 is available at:



A class can be defined outside of any module, and it is possible for that class to use packages from modules, provided that those packages are exported by the modules where they are defined. In particular, a programmer can use classes from the JDK without ever thinking about modules or knowing that they exist. This applies to all the command-line programs in this book. However, when using Java 11 or later, things are different for GUI programs that use JavaFX, which has been removed from the JDK and is distributed as a separate set of modules. As we saw in Section 2.6, when you compile or run a JavaFX program, you need to specify a module path that includes the JavaFX modules, and you need to provide an --add-modules option. (In Section 2.6, the value for --add-modules was given as ALL-MODULE-PATH, which lets the program access any modules that are found on the module path. An alternative is to specify a list of names of just those modules that are actually used by the program.)

Aside from using modules with JavaFX and the basic background information in this section, this textbook does not cover modules.

4.6.5  Javadoc








@param  parameter-name   description-of-parameter
@return  description-of-return-value
@throws  exception-class-name   description-of-exception



 * @param width the length of one side of the rectangle
 * @param height the length the second side of the rectangle
 * @return the area of the rectangle
 * @throws IllegalArgumentException if either the width or the height
 *    is a negative number.
public static double areaOfRectangle( double length, double width ) {
    if ( width < 0  ||  height < 0 )
    double area;
    area = width * height;
    return area; 



4.6.6  Static Import

Before ending this section, I will mention an extension of the import directive. We have seen that import makes it possible to refer to a class such as java.util.Scanner using its simple name, Scanner. But you still have to use compound names to refer to static member variables such as System.out and to static methods such as Math.sqrt.


import static package-name.class-name.static-member-name;

to import one static member name from a class, or

import static package-name.class-name.*;


import static java.lang.System.out;


import static java.lang.Math.*;

This would allow you to say sqrt instead of Math.sqrt, log instead of Math.log, PI instead of Math.PI, and so on. And you could import the getlnInt function from TextIO using

import static textio.TextIO.getlnInt;

