Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4784171

JCK/API comparison: improperly doc'd members inherited from non-accessible class

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: P4 P4
    • None
    • 5.0
    • tools

      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

            Unassigned Unassigned
            dkramersunw Douglas Kramer (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: