This bug has been fixed in 1.5.0.I think we have a regression that I and others have run across.  
I don't think we would be allowed to fix this in 1.4.2, but
I would like to document any workaround in 1.4.2.

Running javadoc on a typical source file, CustomTags.java works just 
fine.  This source file has no package statement and so can be properly 
placed in any directory.

The problem is when another source file, Class1.java, is added to the 
directory holding CustomTags.java -- then an InvocationTargetException
is thrown.  There seem to be two conditions that must be met for
this error to be thrown:
 - Class1.java must be linked to from CustomTags.java, which it is 
   with "@see Class1", and
 - Class1.java must not be in a directory that corresponds to its package
   statement, in this case "package com.package1".

Here, I run javadoc on CustomTags.java without Class1.java present:

% cd ~/javadoc/1.4/bug-4835749-invocationtargetexception
% ls -F
CustomTags.java  
run

% more run
/jdk/1.4.2/latest/binaries/solaris-sparc/bin/javadoc -d html CustomTags.java

% run

This works fine, generating docs as expected.

But if I move a source file Class1.java that CustomTags.java links
to (with @see Class1) into the current directory, then I get an
InvocationTargetException with bad class file ./Class1.java:

% mv dir/Class1.java .

% run
Loading source file CustomTags.java...
Constructing Javadoc information...
Standard Doclet version 1.4.2-beta
Generating html/constant-values.html...
Building tree for all the packages and classes...
Building index for all the packages and classes...
Generating html/overview-tree.html...
Generating html/index-all.html...
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.ClassReader$BadClassFile: bad class file: ./Class1.java
file does not contain class Class1
Please remove or make sure it appears in the correct subdirectory of the classpath.
        at com.sun.tools.javac.v8.JavaCompiler.complete(JavaCompiler.java:304)
        at com.sun.tools.javac.v8.code.ClassReader.fillIn(ClassReader.java:1093)
        at com.sun.tools.javac.v8.code.ClassReader.complete(ClassReader.java:1049)
        at com.sun.tools.javac.v8.code.Symbol.complete(Symbol.java:372)
        at com.sun.tools.javac.v8.code.Symbol$ClassSymbol.complete(Symbol.java:691)
        at com.sun.tools.javac.v8.code.Symbol$ClassSymbol.members(Symbol.java:593)
        at com.sun.tools.javadoc.ClassDocImpl.searchMethod(ClassDocImpl.java:648)
        at com.sun.tools.javadoc.ClassDocImpl.findMethod(ClassDocImpl.java:636)
        at com.sun.tools.javadoc.SeeTagImpl.findExecutableMember(SeeTagImpl.java:303)
        at com.sun.tools.javadoc.SeeTagImpl.findReferenced(SeeTagImpl.java:260)
        at com.sun.tools.javadoc.SeeTagImpl.<init>(SeeTagImpl.java:52)
        at com.sun.tools.javadoc.Comment$1CommentStringParser.parseCommentComponent(Comment.java:147)
        at com.sun.tools.javadoc.Comment$1CommentStringParser.parseCommentStateMachine(Comment.java:101)
        at com.sun.tools.javadoc.Comment.<init>(Comment.java:173)
        at com.sun.tools.javadoc.DocImpl.comment(DocImpl.java:74)
        at com.sun.tools.javadoc.DocImpl.tags(DocImpl.java:104)
        at com.sun.tools.doclets.standard.AbstractIndexWriter.printComment(AbstractIndexWriter.java:187)
        at com.sun.tools.doclets.standard.AbstractIndexWriter.printDescription(AbstractIndexWriter.java:172)
        at com.sun.tools.doclets.standard.AbstractIndexWriter.generateContents(AbstractIndexWriter.java:90)
        at com.sun.tools.doclets.standard.SingleIndexWriter.generateIndexFile(SingleIndexWriter.java:75)
        at com.sun.tools.doclets.standard.SingleIndexWriter.generate(SingleIndexWriter.java:52)
        at com.sun.tools.doclets.standard.Standard.startGeneration(Standard.java:119)
        at com.sun.tools.doclets.standard.Standard.start(Standard.java:43)
        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:193)
        at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:92)
        at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:311)
        at com.sun.tools.javadoc.Start.begin(Start.java:121)
        at com.sun.tools.javadoc.Main.execute(Main.java:41)
        at com.sun.tools.javadoc.Main.main(Main.java:31)
1 error


The error does not occur if "@see Class1.java" is removed from
CustomTags.java.

This is a regression, because when using javadoc 1.3.1, this example
runs fine with no error.  

Oddly, if you pass the *invalid* Class1.java into javadoc, it is
documented just fine with no warnings or errors, if passed in as a
.java file (rather thana package name):

   javadoc Class1.java

N/A

 xxxxx@xxxxx  wrote (to paraphrase) 2003-03-24:

This is not a bug.  Javadoc is being exposed to a bad file in its source 
path so it complains.  Class1.java is invalid because it belongs in package
com.package1, but it is not in the appropriate package.  It is sitting in
directory bug-4835749-invocationtargetexception, which is not right.
Class1.java is attempted to be loaded because CustomTags.java links 
to Class1.java with an @see tag.

If you remove the package statement in Class1.java, the error goes away
and it runs fine.  Or if you move Class1.java to com/package1/Class1.java, 
the error goes away.

However, keep in mind this exception is not thrown in 1.3.1.  Is this 
a regression we should fix, or is it proper to throw the exception?
If the latter case, -- can we please change the error message to something 
more helpful, such as:

  com.package.Class1 not found in directory com/package1 off sourcepath

 xxxxx@xxxxx  2003-04-24

Changed synopsis from:
   InvocationTargetException when generating doc w/ other .java file in current dir

   InvocationTargetException when src file links to another src file in wrong dir


======================

This bug has actually been fixed in 1.5.0.  I added a regression test to verify this.
 xxxxx@xxxxx  2003-12-01

i need to download gava on my system