JDK-4784171 : JCK/API comparison: improperly doc'd members inherited from non-accessible class
  • Type: Bug
  • Component: tools
  • Sub-Component: javadoc(tool)
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: other
  • CPU: generic
  • Submitted: 2002-11-25
  • Updated: 2014-05-05
  • Resolved: 2002-11-25
Related Reports
Duplicate :  
Description
JckApiCompare.pl has been run on 1.4.2-b07

While testing the changes we ran the script and also Setup separately
against the latest JDK build we had: 1.4.2-b07 (and API javadoc
documentation bundled with this build).
Here is what was discovered.

The script outputs the diagnostic message:
   Documented class is not public API:
       java.util.jar.JavaUtilJarAccessImpl
This means that the class is specified in the javadoc spec but it is
not present in the sig-file from the JCK 1.4a. That is, this class
was not public in JDK 1.4.0 and 1.4.1.

==> This has been corrected by making JavaUtilJarAccessImpl package private


Also, we revealed a number of discrepancies between the javadoc spec
and the API binaries of the build b07:

(1) In the class descriptions
  java.awt.BufferCapabilities$FlipContents
  java.awt.JobAttributes$DefaultSelectionType
  java.awt.JobAttributes$DestinationType
  java.awt.JobAttributes$DialogType
  java.awt.JobAttributes$MultipleDocumentHandlingType
  java.awt.JobAttributes$SidesType
  java.awt.PageAttributes$ColorType
  java.awt.PageAttributes$MediaType
  java.awt.PageAttributes$OrientationRequestedType
  java.awt.PageAttributes$OriginType
  java.awt.PageAttributes$PrintQualityType

the methods 
  hashCode()
  toString()

are specified as declared in these classes while in fact in all cases
they are inherited from the class
  java.awt.AttributeValue

==> This is a known bug in the javadoc tool:
    4780441: Incorrectly documents inherited elements from non-public base class  

    The methods actually reside in AttributeValue, which is package-private.
    Javadoc mistakenly documents hashCode() and toString() as implemented 
    in the extended classes rather than documenting them as inherited 
    from a non-accessible superclass (AttributeValue).


(2) In the class descriptions
  java.util.jar.JarEntry
  java.util.jar.JarFile
  java.util.jar.JarInputStream
  java.util.jar.JarOutputStream
  java.util.zip.ZipEntry
  java.util.zip.ZipFile
  java.util.zip.ZipInputStream
  java.util.zip.ZipOutputStream

the majority of the fields
  CENATT
  CENATX ...

are specified to be inherited from the wrong class while they
are in fact inherited from the non-public interface 
  java.util.zip.ZipConstants

==> This is a variant on the above bug in the javadoc tool.
    The fields actually reside in ZipConstants, which is a
    package-private interface.  Javadoc mistakenly documents 
    them as residing in java.util.zip.ZipEntry, a public class 
    that implements ZipConstants, rather than documenting them
    as inherited from a non-accessible interface (ZipConstants).
    
  
(3) In the class description
  javax.swing.text.GapContent
  
the methods  
  getGapEnd()
  getGapStart()
  replace(int,int,java.lang.Object,int)

are specified as declared in this class while in fact they are
inherited from the class
  javax.swing.text.GapVector 

==> This is another variant on the above bug in the javadoc tool.
    The methods actually reside in GapVector, a 
    package-private abstract class.  Javadoc mistakenly
    documents them as residing in GapContents, a public
    class that extends GapVector, rather than documenting
    them as inherited from a non-accessible class (GapVector).
  

I am not sure if these are errors in the spec, just thought it
may be of interest for you.

Thanks,
Dima

Comments
EVALUATION As these bugs are all variants of: 4780441: Incorrectly documents inherited elements from non-public base class I will close out this request as a duplicate of that bug. ###@###.### 2002-11-25
25-11-2002