javadoc - Unix, Linux Command

NAME

SYNOPSIS

PARAMETERS

DESCRIPTION

You can run the Javadoc tool on entire packages, individual source files, or both. In the first case, you pass in as an argument to javadoc a series of package names. In the second case, you pass in a series of source (.java) file names. See EXAMPLES at the end of this document.

NOTE - When you pass in package names to the Javadoc tool, it currently processes all .java classes in the specified package directories, even if the .java files are code examples or other classes that are not actually members of the specified packages. It does not parse each .java file for a package declaration; we may add this parsing in a future release.

During a run, the Javadoc tool automatically adds cross-reference links to package, class and member names that are being documented as part of that run. Links appear in several places:

o Declarations (return types, argument types, field types)

The Javadoc tool produces one complete document each time it is run; it cannot do incremental builds - that is, it cannot modify or directly incorporate results from previous runs of Javadoc. However, it can link to results from other runs, as just mentioned.

As implemented, the Javadoc tool requires and relies on the java compiler to do its job. The Javadoc tool calls part of javac to compile the declarations, ignoring the member implementation. It builds a rich internal representation of the classes, including the class hierarchy, and "use" relationships, then generates the HTML from that. The Javadoc tool also picks up user-supplied documentation from documentation comments in the source code.

In fact, the Javadoc tool will run on .java source files that are pure stub files with no method bodies. This means you can write documentation comments and run the Javadoc tool in the earliest stages of design while creating the API, before writing the implementation.

Relying on the compiler ensures that the HTML output corresponds exactly with the actual implementation, which may rely on implicit, rather than explicit, source code. For example, the Javadoc tool will document default constructors (section 8.6.7 of Java Language Specification) that are present in the .class files but not in the source code.

In many cases, the Javadoc tool allows you to generate documentation from source files whose code is incomplete or erroneous. This is a benefit that enables you to generate documentation before all debugging and troubleshooting is done. For example, according to the Java Language Specification, a class that contains an abstract method should itself be declared abstract. The Javadoc tool does not check for this, and would proceed without a warning, whereas the javac compiler stops on this error. The Javadoc tool does do some primitive checking of doc comments. Use the DocCheck doclet to check the doc comments more thoroughly.

When the Javadoc tool builds its internal structure for the documentation, it loads all referenced classes. Because of this, the Javadoc tool must be able to find all referenced classes, whether bootstrap classes, extensions, or user classes. For more about this, see How Classes Are Found. Generally speaking, classes you create must either be loaded as an extension or in the Javadoc tool’s class path.

javadoc Doclets

Related Documentation and Doclets

Terminology

Source Files

Class Source Code Files

Package Comment Files

To create a package comment file, you must name it package.html and place it in the package directory in the source tree along with the .java files. The Javadoc tool will automatically look for this filename in this location. Notice that the filename is identical for all packages. For explicit details, see the example of package.html.

The content of the package comment file is one big documentation comment, written in HTML, like all other comments, with one exception: The documentation comment should not include the comment separators /** and */ or leading asterisks. When writing the comment, you should make the first sentence a summary about the package, and not put a title or any other text between <body> and the first sentence. You can include package tags; as with any documentation comment, all tags except {@link} must appear after the description. If you add a @see tag in a package comment file, it must have a fully qualified name.

When the Javadoc tool runs, it automatically looks for this file; if found, the Javadoc tool does the following:

Overview Comment File

To create an overview comment file, you can name the file anything you want, typically overview.html, and place it anywhere, typically at the top level of the source tree. Notice that you can have multiple overview comment files for the same set of source files, in case you want to run javadoc multiple times on different sets of packages. For example, if the source files for the java.applet package are contained in /home/user/src/java/applet directory, you could create an overview comment file at /home/user/src/overview.html.

The content of the overview comment file is one big documentation comment, written in HTML, like the package comment file described previously. See that description for details. To reiterate, when writing the comment, you should make the first sentence a summary about the application or set of packages, and not put a title or any other text between <body> and the first sentence. You can include overview tags; as with any documentation comment, all tags except {@link} must appear after the description. If you add a @see tag, it must have a fully-qualified name.

When you run the Javadoc tool, you specify the overview comment file name with the -overview option. The file is then processed, similar to that of a package comment file:

Miscellaneous Unprocessed Files

To include unprocessed files, put them in a directory called doc-files, which can be a subdirectory of any package directory. You can have one such subdirectory for each package. You might include images, example code, source files, .class files, applets, and HTML files. For example, if you want to include the image of a button button.gif in the java.awt.Button class documentation, you place that file in the /home/user/src/java/awt/doc-files/ directory. Notice the doc-files directory should not be located at /home/user/src/java/doc-files because java is not a package - that is, it does not directly contain any source files.

All links to these unprocessed files must be hard-coded, because the Javadoc tool does not look at the files - it simply copies the directory and all its contents to the destination. For example, the link in the Button.java doc comment might look like:

/**
* This button looks like this:
* <img src="doc-files/Button.gif">
*/

Test Files and Template Files

If you run the Javadoc tool by explicitly passing in individual sourcefilenames, you can deliberately omit test and templates files andprevent them from being processed. However, if you are passing in package names or wildcards, you need to follow certain rulesto ensure these test files and templates files are not processed.

Test files differ from template files in that the former arelegal, compilable source files, while the latter are not, but may end with ".java".

If your test files contain doc comments, you can set up a separate run of the Javadoc tool to produce documentation of the test files by passing in their test source filenames with wildcards, such as com/package/    est-filesjava .

Generated Files

Basic Content Pages

Cross-Reference Pages

Support Files

HTML Frames

If you are unfamiliar with HTML frames, you should be aware that frames can have focus for printing and scrolling. To give a frame focus, click on it. Then, on many browsers the arrow keys and page keys will scroll that frame, and the print menu command will print it.

    ------------                  ------------
    |C| Detail |                  |P| Detail |
    | |        |                  | |        |
    | |        |                  |-|        |
    | |        |                  |C|        |
    | |        |                  | |        |
    | |        |                  | |        |
    ------------                  ------------
   javadoc *.java           javadoc java.lang java.awt

Load one of the following two files as the starting page depending on whether you want HTML frames or not:

Generated File Structure

For example, the document generated for the class java.applet.Applet would be located at java/applet/Applet.html. The file structure for the java.applet package follows, given that the destination directory is named apidocs. All files that contain the word "frame" appear in the upper-left or lower-left frames, as noted. All other HTML files appear in the right-hand frame.

NOTE: Directories are shown in bold. The asterisks (*) indicate the files and directories that are omitted when the arguments to javadoc are source file names (*.java) rather than package names. Also, when arguments are source file names, package-list is created but is empty. The doc-files directory is not created in the destination unless it exists in the source tree.

Generated API Declarations

public final class Boolean
extends Object
implements Serializable

and the declaration for the Boolean.valueOf method is:

public static Boolean valueOf(String s)

The Javadoc tool can include the modifiers public, protected, private, abstract, final, static, transient, and volatile, but not synchronized or native. These last two modifiers are considered implementation detail and not part of the API specification.

Rather than relying on the keyword synchronized, APIs should document their concurrency semantics in the comment description, as in "a single Enumeration cannot be used by multiple threads concurrently". The document should not describe how to achieve these semantics. As another example, while Hashtable should be thread-safe, there’s no reason to specify that we achieve this by synchronizing all of its exported methods. We should reserve the right to synchronize internally at the bucket level, thus offering higher concurrency.

Documentation Comments

Commenting the Source Code

/**
* This is the typical format of a simple documentation comment
* that spans two lines.
*/

To save space you can put a comment on one line:

/** This comment takes up only one line. */

Placement of comments - Documentation comments are recognized only when placed immediately before class, interface, constructor, method, or field declarations (see the class example, method example, and field example). Documentation comments placed in the body of a method are ignored. Only one documentation comment per declaration statement is recognized by the Javadoc tool.

A common mistake is to put an import statement between the class comment and the class declaration. Avoid this, as javadoc will ignore the class comment.

/**
* This is the class comment for the class Whatever.
*/

import com.sun;   // MISTAKE - Important not to put statement here

public class Whatever {
}

A comment is a description followed by tags - The description begins after the starting delimiter /** and continues until the tag section. The tag section starts with the first character @ that begins a line (ignoring leading asterisks and white space). It is possible to have a comment with only tags and no description. The description cannot continue after the tag section begins. The argument to a tag can span multiple lines. There can be any number of tags - some types of tags can be repeated while others cannot. This @see starts the tag section:

 /**
 * This is a doc comment.
 * @see java.lang.Object
 */

Standard and in-line tags - A tag is a special keyword within a doc comment that the Javadoc tool can process. The Javadoc tool has standalone tags, which appear as @tag, and in-line tags, which appear within braces, as {@tag}. To be interpreted, a standalone tag must appear at the beginning of a line, ignoring leading asterisks, white space and comment separator (/**). This means you can use the @ character elsewhere in the text and it will not be interpreted as the start of a tag. If you want to start a line with the @ character and not have it be interpreted, use the HTML entity @. Each standalone tag has associated text, which includes any text following the tag up to, but not including, either the next tag, or the end of the doc comment. This associated text can span multiple lines. An in-line tag is allowed and interpreted anywhere that text is allowed. The following example contains the standalone tag @deprecated and in-line tag {@link}.

/**
 * @deprecated As of JDk 1.1, replaced by {@link #setBounds(int,int,int,int)}
 */

Comments are written in HTML - The text must be written in HTML, in that they should use HTML entities and HTML tags. You can use whichever version of HTML your browser supports; we have written the standard doclet to generate HTML 3.2-compliant code elsewhere (outside of the documentation comments) with the inclusion of cascading style sheets and frames. (We preface each generated file with "HTML 4.0" because of the frame sets.)

For example, entities for the less-than (<) and greater-than (>) symbols should be written < and >. Likewise, the ampersand (&) should be written &. The bold HTML tag <b> is shown in the following example:

/**
* This is a <b>doc</b> comment.
* @see java.lang.Object
*/

Leading asterisks - When javadoc parses a doc comment, leading asterisk (*) characters on each line are discarded; blanks and tabs preceding the initial asterisk (*) characters are also discarded. If you omit the leading asterisk on a line, all leading white space is removed. Therefore, you should not omit leading asterisks if you want leading white space to be kept, such as when indenting sample code with the <pre> tag.

First sentence - The first sentence of each doc comment should be a summary sentence, containing a concise but complete description of the declared entity. This sentence ends at the first period that is followed by a blank, tab, or line terminator, or at the first standalone tag. The Javadoc tool copies this first sentence to the member summary at the top of the HTML page.

Declaration with multiple fields - Java allows declaring multiple fields in a single statement, but this statement can have only one documentation comment, which is copied for all fields. Therefore, if you want individual documentation comments for each field, you must declare each field in a separate statement. For example, the following documentation comment doesn’t make sense when written as a single declaration and would be better handled as two declarations:

/**
* The horizontal and vertical distances of point (x,y)
*/
public int x, y;      // Avoid this

The Javadoc tool generates the following documentation from the above code:

public int x The horizontal and vertical distances of point (x,y).

public int y

Use header tags carefully - When writing documentation comments for members, it is best not to use HTML heading tags such as <H1> and <H2>, because the Javadoc tool creates an entire structured document and these structural tags can interfere with the formatting of the generated document. However, it is fine to use these headings in class and package comments to provide your own structure.

Automatic Reuse of Method Comments

More specifically, when a @param tag for a particular parameter is missing, then the comment for that parameter is copied. When an @throws tag for a particular exception is missing, the @throws tag is copied only if that exception is declared.

This behavior contrasts with version 1.3 and earlier, where the presence of any description or tag would prevent all comments from being inherited.

Also of interest, is the inline tag {@inheritDoc} is present in a description or any tag, the corresponding description or tag is copied at that spot.

The overridden method must be a member of a documented class, and not an external referenced class for the doc comment to actually be available to copy.

Inheriting of comments occurs in three cases:

In the third case, when a method in a given class implements a method in an interface, the Javadoc tool generates a subheading "Specified by" in the documentation for the overriding method, with a link to the method it is implementing.

Algorithm for Inheriting Method Descriptions If a method does not have a doc comment, the Javadoc tool searches for an applicable comment using the following algorithm, which is designed to find the most specific applicable doc comment, giving preference to interfaces over superclasses:

a. If the superclass has a doc comment for this method, use it.
b. If step 3a failed to find a doc comment, recursively apply this
entire algorithm to the superclass.

javadoc Tags

Tags come in two types:

o Standalone tags - Can be placed only in the tag section that follows the desription. There tags are not set off with curly braces: @tag.

o Inline tags - Can be placed anywhere in the comments description or in the comments for standalone tags. Inline tags are set off with curly braces:{@tag}.

For information about tags we might introduce in future releases, see Proposed Tags.

The current tags are:

For custom tags, see the -tag option.

/**
 * @deprecated  As of JDK 1.1, replaced by
 *    {@link #setBounds(int,int,int,int)}
 */

{@code A<B>C}

displays in the generated HTML page unchanged as:

A<B>C

The noteworthy point is that the <B> is not interpreted as boldand is in code font.

If you want the same functionality without the code font, use {@literal}.

/**
* See the <a href="{@docRoot}/copyright.html">Copyright</a>.
*/

Use the {@link #getComponentAt(int, int) getComponentAt} method.

Use the
<a href="Component.html#getComponentAt(int, int)">\
               getComponentAt</a>method.

Use the getComponentAt method.

Refer to {@linkplain add() the overridden method}.

Refer to the overridden method.

If you want the same functionality but with the text in code font, use {@code} .

,nf /** * @param <E> Type of element stored in a list */ public interface List<E> extends Collection<E> { }

For more details, see writing @param tags.

     @see "The Java Programming Language"

     See Also:
          "The Java Programming Language"

     @see <a href="spec.html#section">Java Spec</a>

    See Also:
          Java Spec

      /**
      * @see String#equals(Object) equals
      */

    <dl>
    <dt><b>See Also:</b>
    <dd><a href="../../java/lang/String#equals\
                 (java.lang.Object)"><code>equals</code></a>
    </dl>

     See Also:
          equals

@since 1.4

/**
* The value of this constant is {@value}.
*/
public static final String SCRIPT_START = "<script>"

/**
* Evaluates the script starting with {@value #SCRIPT_START}.
*/
public String evalScript(String script) {
}

These values of these constants are also displayed on the Constant Field Values page.

Where Tags Can Be Used

Overview Documentation Tags

NOTE: The {@link} tag has a bug in overview documents in version 1.2. Text appears properly but has no link. The {@docRoot} tag foes not currently work in overview documents.

Package Documentation Tags

Class and Interface Documentation Tags

An example of a class comment:

/**
* A class representing a window on the screen.
* For example:
* <pre>
*    Window win = new Window(parent);
*    win.show();
* </pre>
*
* @author  Sami Shaio
* @version 1.8, 06/24/04
* @see     java.awt.BaseWindow
* @see     java.awt.Button
*/
class Window extends BaseWindow {

}

Field Documentation Tags

An example of a field comment:

/**
* The X-coordinate of the component.
*
* @see #getLocation()
*/
int x = 1263732;

Constructor and Method Documentation Tags

An example of a method doc comment:

/**
* Returns the character at the specified index. An index
* ranges from <code>0</code> to <code>length() - 1</code>.
*
* @param     index  the index of the desired character.
* @return    the desired character.
* @exception StringIndexOutOfRangeException
*              if the index is not in the range <code>0</code>
*              to <code>length()-1</code>.
* @see       java.lang.Character#charValue()
*/
public char charAt(int index) {

}

OPTIONS

The options are:

Javadoc Options

-doclet com.sun.tools.doclets.mif.MIFDoclet

-docletpath /home/user/mifdoclet/lib/mifdoclet.jar

-docletpath /home/user/mifdoclet/classes/com/sun/tools/doclets/mif/

/home/user/src/com/mypackage/*.java

example% javadoc -sourcepath /home/user/src/ com.mypackage

example% javadoc -sourcepath /home/user/src/:/home/user2/src com.mypackage

example% javadoc -classpath /home/user/lib -sourcepath \
               /home/user/src com.mypackage

example% javadoc -J-Xmx32m -J-Xms32m com.mypackage

example% javadoc -J-version
java version "1.2"
Classic VM (build JDK-1.2-V, green threads, sunwjit)

Options Provided by the Standard Doclet

example% javadoc -d /home/user/doc com.mypackage

example% javadoc -windowtitle "Java 2 Platform" com.mypackage

example% javadoc -doctitle "Java<sup><font size=
                        TM</font></sup>" com.mypackage

% javadoc -link http://java.sun.com/j2se/1.4/docs/api com.mypackage

% javadoc -d ./spi -link ../api com.spipackage

Link bug in 1.2 and 1.3 - When @see or {@link}
references an excluded class and -link is used,
an <A HREF> hyperlink is created only if the class is referenced
with in an import statement or in a declaration. References
in the body of methods, alone are inadequate. A workaround
was to include an explicit (not wildcard) import
statement for the referenced class.

import java.lang.SecurityManager; // workaround to force @see/@link\
                                                                                hyperlink

java.applet
java.awt
java.awt.color
java.awt.datatransfer
java.awt.dnd
java.awt.event
java.awt.font
etc.

example% javadoc -link extdocURL1 -link extdocURL2 ... \
   -link extdocURLn com.mypackage

% javadoc -linkoffline http://java.sun.com/j2se/1.4/docs/api . com.mypackage

example% javadoc  -linkoffline docURL1 packagelistURL1 \
                  -linkoffline docURL2 packagelistURL2 \
                  ...

example% javadoc -d update -linkoffline . html com.mypackage

example% javadoc -group "Core Packages" "java.lang*:java.util" \
    -group "Extension Packages" "javax.*" \
    java.lang java.lang.reflect java.util javax.servlet java.new

Core Packages
  java.lang
  java.lang.reflect
  java.util
Extension Packages
  javax.servlet
Other Packages
  java.new

example% javadoc -helpfile /home/doc/myhelp.html java.awt

example% javadoc -stylesheetfile \
            /home/user/mystylesheet.css com.mypackage

<META NAME="keywords" CONTENT="java.lang.String class">
<META NAME="keywords" CONTENT="CASE_INSENSITIVE_ORDER">
<META NAME="keywords" CONTENT="length()">
<META NAME="keywords" CONTENT="charAt()">

X (disable tag)
a (all)
o (overview)
p (packages)
t (types, that is classes and interfaces)
c (constructors)
m (methods)
f (fields)

-tag todo:a:"To Do:"

-tag todo:cmf:"To Do:"

@todo The documentation for this method needs work.

To Do:
                  The documentation for this method needs work.

Use of Colon in Tag Name -
A colon can be used in a tag name if it
is escaped with a backslash. For this comment:

/**
* @ejb:bean
*/

-tag todo:Xcmf:"To Do:"

-tag todo:X

-taglet com.sun.tools.doclets.ToDoTaglet
-tagletpath /home/taglets
-tag return
-tag param
-tag todo
-tag throws
-tag see

% javadoc -d docs -sourcepath /home/user/src \
                  -subackages java:javax.swing

% javadoc -sourcepath /home/user/src -sourcepath java\
                  -exclude java.net:java.lang

-noqualifier all

-noqualifier java.lang:java.io

-noqualifier java.*:com.sun.*

Command Line Argument Files

An argument file can include Javadoc options, source filenames and package names in any combination, or just arguments to Javadoc options. The arguments within a file can be space-separated or newline-separated. Filenames within an argument file are relative to the current directory, not the location of the argument file. Wildcards (*) are not allowed in these lists (such as for specifying *.java). Use of the ’@’ character to recursively interpret files is not supported. The -J options are not supported because they are passed to the launcher, which does not support argument files.

When executing javadoc, pass in the path and name of each argument file with the ’@’ leading character. When javadoc encounters an argument beginning with the character ’@’, it expands the contents of that file in the argument list.

Example - Single Arg File

You could use a single argument file named "argfile" to hold all Javadoc arguments:

% javadoc @argfile

This argument file could contain the contents of both files shown in the next example.

Example - Two Arg Files

You can create two argument files - one for the Javadoc options and the other for the package names or source filenames: (Notice the following lists have no line-continuation characters.)

Create a file named "options" containing:

-d docs-filelist
-use
-splitindex
-windowtitle ’Java 2 Platform v1.3 API Specification’
-doctitle ’Java<sup><font size="-2">TM</font></sup> 2\
                  Platform v1.4 API Specification’
-header ’<b>Java 2 Platform </b><br><font size="-1">v1.4</font>’
-bottom ’Copyright 1993-2000 Sun Microsystems, Inc. All Rights Reserved.’
-group "Core Packages" "java.*"
-overview /java/pubs/ws/1.3/src/share/classes/overview-core.html
-sourcepath /java/pubs/ws/1.3/src/share/classes

Create a file named "packages" containing:

com.mypackage1
com.mypackage2
com.mypackage3

You would then run javadoc with:

% javadoc @options @packages

Example - Arg Files with Paths

The argument files can have paths, but any filenames inside the files are relative to the current working directory (not path1 or path2):

% javadoc @path1/options @path2/packages

Examples - Option Arguments

Here’s an example of saving just an argument to a javadoc option in an argument file. We’ll use the -bottom option, since it can have a lengthy argument. You could create a file named "bottom" containing its text argument:

Submit a bug or feature</a><br><br>Java is a trademark or registered trademark of Sun Microsystems, Inc. in the US and other countries.<br>Copyright 1993-2000 Sun Microsystems, Inc. 901 San Antonio Road,<br>Palo Alto, California, 94303, U.S.A. All Rights Reserved.</font>’

The run the Javadoc tool with:

% javadoc -bottom @bottom @packages

Or you could include the -bottom option at the start of the argument file, and then just run it as:

% javadoc @bottom @packages

RUNNING

Running Javadoc

The version number of javadoc can be determined using javadoc-J-version. The version number of the standard doclet appears in its output stream. It can be turned off with -quiet .

Public programmatic interface -

To invoke the Javadoc tool from within programs written in the Java language. This interface is in om.sun.tools.javadoc.Main (and javadoc is re-entrant). For
more details, see Standard Doclet.

SIMPLE EXAMPLES

Documenting One or More Packages

You can run javadoc either by changing directories (with cd) or by using -sourcepath option. The examples below illustrate both alternatives.

% javadoc -d /home/html -sourcepath /home/src\
                  -subpackages java -exclude java.net:java.lang

example% cd /home/src/
example% javadoc -d /home/html java.awt java.awt.event

example% javadoc -d /home/html -sourcepath /home/src \
           java.awt java.awt.event

% javadoc -d /home/html -sourcepath\
                  /home/src1:/home/src2 java.awt java.awt.event

Documenting One or More Classes

example% cd /home/src/java/awt
example% javadoc -d /home/html Button.java Canvas.java \
               Graphics*.java

example% cd /home/src/
example% javadoc -d /home/html java/awt/Button.java \
                 java/applet/Applet.java

example% javadoc -d /home/html /home/src/java/awt/Button.java \
               /home/src/java/awt/Graphics*.java

Documenting Both Packages and Classes

example% javadoc -d /home/html -sourcepath /home/src java.awt \
               /home/src/java/applet/Applet.java

This example generates HTML-formatted documentation for the package java.awt and class Applet. The Javadoc tool determines the package name for Applet from the package declaration, if any, in the Applet.java source file.)

Real World Example

The same example is shown twice - first as executed on the command line, then as execued from a makefile. It uses absolute paths in the option arguments, which enables the same javadoc command to be run from any directory.

Command Line Example

example% javadoc -sourcepath /jdk/src/share/classes

-overview /java/jdk/src/share/classes/overview.html 
-d /jdk/build/api   
-use                
-splitIndex         
-windowtitle ’Java 2 Platform v1.2 API Specification’ 
-doctitle ’Java<sup><font size="-2">TM</font></sup> 2 \
                    Platform v1.2 API Specification ’ 
-header ’<b>Java 2 Platform </b><br><font size="-1">v1.2</font>’ 
-bottom ’<font size="-1"><a href="http://java.sun.com/cgi-bin/bugreport.cgi"> \
                    Submit a bug or feature</a><br><br>Java is a trademark or registered \
                    trademark of Sun Microsystems,Inc. in the US and other countries.<br> \
                    Copyright 1993-1999 Sun Microsystems, Inc.
      901 San Antonio Road,<br>Palo Alto, California, 94303, U.S.A. \
                    All Rights Reserved.</font>’ 
-group "Core Packages" "java.*:com.sun.java.*:org.omg.*" 
-group "Extension Packages" "javax.*" 

-J-Xmx180m          
@packages

where packages is the name of a file containing the packages to process, such as java.applet, java.lang. None of the options should contain any newline characters between the single quotes. (For example, if you copy and paste this example, delete the newline characters from the -bottom option.) See the other notes listed below.

Makefile Example

example% javadoc -sourcepath /jdk/src/share/classes/* Sets path for
                             source files  */

-overview $ (SRCDIR)/overview.html /* Sets path for overview text */
-d /jdk/build/api   /* Sets destination directory */
-use                /* Adds "Use" files      */
-splitIndex         /* Splits index A-Z      */
-windowtitle $(WINDOWTITLE)/* Adds a window title   */
-doctitle $(DOCTITLE)/* Adds a doc title      */
-header $(HEADER)   /* Adds running header text       */
-bottom $(BOTTOM)   /* Adds text at bottom            */
-group $(GROUPCORE) /* 1st subhead on overview page */
-group $(GROUPEXT)  /* 2nd subhead on overview page  */

-J-Xmx180m          /* Sets memory to 180MB     */
java.lang java.lang.reflect/* Sets packages to document  */
java.util java.io java.netjava.applet

WINDOWTITLE = ’Java Platform 1.2 Final API Specification’
DOCTITLE = ’Java<sup><font size="-2">TM</font></sup> Platform 1.2 \
                 Final API Specification’
HEADER = ’<b>Java Platform 1.2</b><br><font size="-1">Final</font>’

BOTTOM = ’<font size="-1"><a href="http://java.sun.com/cgi-bin/bugreport.cgi">\
              Submit a bug or feature</a><br><br>Java is a trademark or registered \
              trademark of Sun Microsystems, Inc. in the US and other countries.<br> \
              Copyright 1993-1998 Sun Microsystems, Inc. 901 San Antonio Road,<br>\
              Palo Alto, California, 94303, U.S.A.</font>’

GROUPCORE = ’"Core Packages" "java.*:com.sun.java.*:org.omg.*"
GROUPEXT  = ’"Extension Packages" "javax.*"’
SRCDIR = ’/java/jdk/1.2/src/share/classes’

Single quotes are used to surround makefile arguments.

Notes

TROUBLESHOOTING

General Troubleshooting

Errors and Warnings

ENVIRONMENT

SEE ALSO

See (or search java.sun.com) for the following: