...




FULL PRODUCT VERSION :
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

FULL OPERATING SYSTEM VERSION :
Microsoft Windows XP [Version 5.1.2600]


A DESCRIPTION OF THE PROBLEM :
It would appear that the javadoc -bootclasspath option
actually does modify the set of classes used to run the
tool, unlike the documentation states:
A programmer may want to resolve boot class or extension
class references using an alternative Java platform
implementation. Both javac and javadoc support this with
their -bootclasspath and -extdirs options. Use of these
options does not modify the set of class files used to run
the javac or javadoc tools themselves.
<http://java.sun.com/j2se/1.4/docs/tooldocs/findingclasses.h
tml#srcfiles>)

For instance, when compiling documentation for a CLDC
implementation (which includes only a subset of the
java.lang classes found in j2se) if the bootclasspath is
specified and points to the cldc source tree, the javadoc
tool fails to execute with the error:
javadoc:
In doclet class com.sun.tools.doclets.standard.Standard,
method start has thrown an exception
java.lang.reflect.InvocationTargetException
com.sun.tools.javac.v8.code.Symbol$CompletionFailure: file
java\io\Serializable.class not found

notice that in this case, serializable is not part of the
CLDC class set, which suggests that javadoc is using the
path provided by the bootclasspath option to resolve
internal class references.

Also, if the bootclasspath option is NOT specified,
execution of the javadoc tool completes successfully,
However, the doc tree for the packages in java.* include
classes that are NOT part of the original source tree (note
also that this behaviour is observed when both sourcepath
and classpath options are specified and point to, for
example, the CLDC implementation tree). This last point is
perhaps related to bug 4548768.

REGRESSION.  Last worked in version 1.3.1

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Create a CLDC implementation (java.lang, java.io,
java.util, javax.microedition.io) in a container directory
cldc for example.
2. run javadoc on the tree:
javadoc -d docs -sourcepath cldc -classpath cldc -bootclasspath -cldc java.lang java.io java.util
3.

EXPECTED VERSUS ACTUAL BEHAVIOR :
Expected result is successful completion of the javadoc
tool.
Actual result is a failure while processing.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
javadoc: In doclet class com.sun.tools.doclets.standard.Standard,  method start
has thrown an exception java.lang.reflect.InvocationTargetException
com.sun.tools.javac.v8.code.Symbol$CompletionFailure: file
java\io\Serializable.class not found
        at com.sun.tools.javac.v8.code.ClassReader.fillIn(ClassReader.java:1020)
        at com.sun.tools.javac.v8.code.ClassReader.complete
(ClassReader.java:977)
        at com.sun.tools.javac.v8.code.Symbol.complete(Symbol.java:375)
        at com.sun.tools.javac.v8.code.Symbol$ClassSymbol.complete
(Symbol.java:697)
        at com.sun.tools.javac.v8.code.Symbol$ClassSymbol.flags(Symbol.java:594)
        at com.sun.tools.javac.v8.code.Type$ClassType.isSubType(Type.java:1073)
        at com.sun.tools.javadoc.ClassDocImpl.isSerializable
(ClassDocImpl.java:848)
        at com.sun.tools.doclets.standard.tags.SeeTaglet.toString
(SeeTaglet.java:103)
        at com.sun.tools.doclets.standard.HtmlStandardWriter.generateTagInfo
(HtmlStandardWriter.java:1494)
        at com.sun.tools.doclets.standard.ClassWriter.generateClassFile
(ClassWriter.java:234)
        at com.sun.tools.doclets.standard.ClassWriter.generate
(ClassWriter.java:95)
        at com.sun.tools.doclets.standard.Standard.generateClassCycle
(Standard.java:245)
        at com.sun.tools.doclets.standard.Standard.generateClassFiles
(Standard.java:200)
        at com.sun.tools.doclets.standard.Standard.startGeneration
(Standard.java:166)
        at com.sun.tools.doclets.standard.Standard.start(Standard.java:44)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:324)
        at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:196)
        at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:95)
        at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:288)
        at com.sun.tools.javadoc.Start.begin(Start.java:114)
        at com.sun.tools.javadoc.Main.execute(Main.java:44)
        at com.sun.tools.javadoc.Main.main(Main.java:34)

This bug can be reproduced always.
(Review ID: 143524) 
======================================================================

N/A

This is a bug in the tool, but it isn't an issue of the tool's
own bootstrap class being wrong.  The tool decides if a class is
serializable by seeing if it extends Serializable.  The tool
is crashing because that class doesn't "exist" in the user's
bootstrap class set.

Javadoc (the tool) should not crash on CLDC.  Rather, it should
consider nothing serializable when there is no Serializable class
in the bootstrap class path.

 xxxxx@xxxxx  2002-02-28