Generates HTML pages of API documentation from compiled .class or .jar files.
Copyright © Jens Gulden email@example.com
This software comes with absolutely NO WARRANTY. See file licence.txt for details.
java -cp classdoc.jar;java_home/lib/tools.jar;dirs_or_jars classdoc -docpath dirs_or_jars ( -public | -protected | -packageprivate | -private ) (-1.1) (-doclet class) (-verbose) (-nofakepublic) [doclet-options] | -help
-linkoffline url url2
-group name p1:p2..
classdoc parses compiled Java class files in directories or archive-files and produces a corresponding set of HTML pages describing classes, inner classes, interfaces, constructors, methods, and fields. By default, the public and protected fields and members are described. Classdoc does not need source codes to generate the documentation. You can reverse-engineer vitually any Java-written and compiled program.
An example is given at the end of this document.
As classdoc implements the Java Doclet API, it can incorporate any doclet to generate output in different formats. See See Javadoc Doclets.
When classdoc builds the documentation, it loads all classes referenced in the declarations of the classes in the docpath. This is the reason why classdoc must be able to load these classes from the classpath.
The content and format of classdoc's output can be customized by using doclets. By default, classdoc uses the Standard Doclet belonging to the javadoc-tool that ships with the Java Development Kit 1.3 to generate HTML-formatted API documentation. You can write your own doclet to generate whatever output format you'd like or you can download a third party doclet.
Javadoc Tool documenation for details about generating HTML-based API documentation and using doclets.
Javadoc Enhancements for an overview on doclet technology.
Doclet API for details on developing Doclets.
Classdoc will generate output originating from compiled class files only. Source files neither have to nor even can be incorporated in generating classdoc's output.
Each directory that is contained in the docpath (see command line option -docpath) is recursively searched for class files. Any class that is found and that matches the desired access modifiers (-public/-protected/...) will be included in the documentation. Note that, as known from classpath settings, the structure of subdirectories in the specified directory must match the classes' package structure.
Each archive file that is contained in the docpath (see command line option -docpath) is searched for class files. Any class that is found and that matches the desired access modifiers (-public/-protected/...) will be included in the documentation.
Note: in order to make all classes in the docpath available to classdoc's class loader, any directory and archive included in the docpath must also be accessible in the classpath.
By default, classdoc uses JDK 1.3's Standard Doclet to generate HTML-formatted documentation. This doclet generates two groups of files: those describing classes/interfaces (having the same name as the described item), and those that are internally generated parts of the HTML documenation. (E.g.
package-summary.html). Internally generated files contain hyphens to prevent filenames to conflict with class / interface descriptions. Refer to the Generated Files section in the Javadoc Tool Documentation for more detailled information about files generated by the Standard Doclet.
The following example creates reverse engineered documentation of the classes in JDK's archive tools.jar, including all private classes and members. The HTML files are created in directory c:\tmp. Run this as a batch-file (.bat) on a Windows 9x system.
set CLASSDOC=d:\java\classdoc set JAVA=d:\java\jdk1.3 set DOCPATH=%JAVA%\lib\tools.jar set TARGET=c:\tmp %JAVA%\bin\java -cp %JAVA%\lib\tools.jar;%CLASSDOC%\classdoc.jar;%DOCPATH% classdoc -docpath %DOCPATH% -private -d %TARGET% -windowtitle "tools.jar documentation - reverse engineered by classdoc" -header "Generated by <b>classdoc</b>" -verbose
(Note that here tools.jar appears twice in the classpath, because it is also the value of DOCPATH. This is to illustrate that both tools.jar and the classes to be documented must be part of the classpath. In this example, these are the same.)
Some limitations and bugs apply to the current version:
The generated HTML documentation does not contain hyperlinks (e.g. you cannot click on a method name to directly get to its documentation). This is considered a bug, as it affects the flexibility of navigation through the documentation. However, any information stays accessible through frame-based navigation.
Inner class names are displayed with '$' as the delimiting character between the name of the corresponding outer class and the actual inner class's name. This matches the filename convention for class files. The actual Java language convention, however, uses a '.' like in 'outerClass.innerClass'.
Names are sorted differetly than javadoc does. This way, in a sorted list classnames might appear in a different order than they would in a correspondig documentation generated by javadoc, if classnames starting with lower cases are involved. However, classes are usually not named in lowercase, so this is just an aesthetical question, no bug.
To run classdoc, use a Java Development Kit (JDK) 1.3 (or higher). A Java Runtime Environment (JRE) is not sufficient as it does not provide the classes of the Doclet API and the Standard Doclet.
The classpath should provide access to the following archives:
This archive contains the Doclet API interface classes and the Standard Doclet's classes.
All classes that are to be documented must both be present in the classpath and the docpath.
Of course, the Java 2 API classes in archive rt.jar must also be part of the classpath. However, when using option -cp to specify additional classpath components, you do not need to take care about this.
Javadoc 1.3 Tool Documentation.