javadoc in 1.4.2 generates incorrect html file which has incorrect link target.

REPRODUCE :
(1) Unfold the attached zip file, javadoc_test.zip
(2) Invoke go.bat in 1.4.2_0X

BEHAVIOR :
 Please see the api2/pkg2/Test21.html. This html file includes the following 3 incorrect
 link targets.
 
  a) http://test/api1/pkg1/sub1.Test12.html   ( (1) in attached javadoc-link-diff.JPG)
  b) http://test/api1/pkg3/Test31.html        ( (2) in attached javadoc-link-diff.JPG)
  c) http://test/api1/pkg3/sub3.Test32.html   ( (2) in attached javadoc-link-diff.JPG)

 As to sub1.Test12.html in a) and sub3.Test32.html in c),
 those files are not created, but are set as link targets.
 
As to b), Test31.html is exist. However, this file is under ./api3/pkg3, but under ./api1/pkg3.

NOTE:
 This behavior seems to occur in 1.4.2, but in 1.4.1 and 5.0.
Posted Date : 2005-10-04 08:15:42.0

N/A

The bug submitter says these links are invalid:

a) http://test/api1/pkg1/sub1.Test12.html
b) http://test/api1/pkg3/Test31.html     
c) http://test/api1/pkg3/sub3.Test32.html  

However, these parameters say "All classes in packages api1 and api3 can be found at http://test/api1/".

-linkoffline http://test/api1/ api1 
-linkoffline http://test/api1/ api3

I only agree that c) is a bad link.  We should not try linking to classes in package pkg3.sub3 because it is not specified in api3/package-list.
Posted Date : 2005-11-16 06:17:54.0

This bug is very much related to 4724216.  The main problem here is that package-list does not have enough information to determine whether the class can really be externally linked.  In this case, the doclet is fooled into linking to inner class sub3.Test32 in package pkg3.  The doclet does not know that sub3 is really a subpackage because package-list does not say so.  In a future release, perhaps we should have fully qualied class names in our link file.  That way, we won't like to pkg3.sub3.Test32 if it is not found in the file.
Posted Date : 2005-11-25 19:36:14.0