Java Reference
In-Depth Information
documentation by default, but this is because it uses a doclet that produces
HTML documentation. You can write your own doclet that produces whatever
format you wish. Most find the HTML documentation so satisfactory that
custom doclets are rare.
Javadoc can be a large topic, because it not only documents all classes,
methods, and class variables, but can also use detailed text from specially for-
matted comments in the source code. We will cover Javadoc comments only
briefly here, but you will see examples in our project code throughout this topic.
5.5.1
The javadoc command has the following general form:
Running javadoc
javadoc [ options ...] [ package names ...] [ source filenames ...]
[ @optfile ...]
Options are covered in the next section. You can specify the classes to
document in two ways. First, you can list one or more Java packages on the
command line. Source code for the named packages is searched for on the
source classpath (see Section 5.5.2). Wildcards are not permitted in
package names.
Second, you may list as many Java source files as you like, and you may
use wildcards in the names.
As with the javac compiler above, the @optfile allows you to name a text
file whose lines are treated as arguments as if they had been typed on the com-
mand line.
Example 5.5 shows how to run javadoc on our small multiclass sample.
In this case, we were in the “base directory” of the package when we ran
the command. In other words, net was a subdirectory of the current working
directory when we ran Javadoc. Javadoc uses the same default classpaths and
environment variables as javac does, so by default “ . ” is on the path.
Generally, specifying packages is the most convenient way to document a
number of classes, since packages are how collections of classes are generally
managed in Java development.
Figure 5.1 shows the main screen of the documentation thus produced.
Search WWH ::




Custom Search