-
Bug
-
Resolution: Unresolved
-
P4
-
1.4.2
If a class is serializable, by default javadoc will create an entry for it on the Serialized Form page, and add a link to this entry from the See Also section of the class doc. This entry names the serializable class, along with its superclass and "implements Serializable". Unfortunately, the superclass is included on the Serialized Form page, even if that superclass is not serializable.
In general, if a serializable class has a non-serializable superclass, there is no reference to that superclass in the serialized bytestream. Since the Serialized Form page is intended to document the actual serialized bytestream, a non-serializable superclass should not appear on the Serialized Form page.
(Note also that if a serializable class has a serializable superclass, that superclass *does* appear in the serialized bytestream, even if it is a (package) private class. Thus, a serializable superclass *should* appear on the Serialized Form page, even if that superclass is private.)
Here are a couple examples of where this occurs in the current API.
* java.util.ArrayList (serializable) is a subclass of java.util.AbstractList (public, non-serializable). The entry on the Serialized Form page for ArrayList includes
Class java.util.ArrayList extends AbstractList<E> implements Serializable
AbstractList should not be present.
* java.lang.StringBuffer (serializable) is a subclass of java.lang.AbstractStringBuilder (private, non-serializable). The entry on the Serialized Form page for StringBuffer includes:
Class java.lang.StringBuffer extends java.lang.AbstractStringBuilder implements Serializable
AbstractStringBuilder should not be present.
* java.util.BitSet (serializable) is a subclass of Object (public, non-serializable). The entry on the Serialized Form page for BitSet includes:
Class java.util.BitSet extends Object implements Serializable
Object should not be present. There are many other examples on the Serialized Form page that include "extends Object". Obviously every class is a descendant of Object, but Object itself does not appear in the serialized bytestream, so "extends Object" shouldn't appear on the Serialized Form page.
In general, if a serializable class has a non-serializable superclass, there is no reference to that superclass in the serialized bytestream. Since the Serialized Form page is intended to document the actual serialized bytestream, a non-serializable superclass should not appear on the Serialized Form page.
(Note also that if a serializable class has a serializable superclass, that superclass *does* appear in the serialized bytestream, even if it is a (package) private class. Thus, a serializable superclass *should* appear on the Serialized Form page, even if that superclass is private.)
Here are a couple examples of where this occurs in the current API.
* java.util.ArrayList (serializable) is a subclass of java.util.AbstractList (public, non-serializable). The entry on the Serialized Form page for ArrayList includes
Class java.util.ArrayList extends AbstractList<E> implements Serializable
AbstractList should not be present.
* java.lang.StringBuffer (serializable) is a subclass of java.lang.AbstractStringBuilder (private, non-serializable). The entry on the Serialized Form page for StringBuffer includes:
Class java.lang.StringBuffer extends java.lang.AbstractStringBuilder implements Serializable
AbstractStringBuilder should not be present.
* java.util.BitSet (serializable) is a subclass of Object (public, non-serializable). The entry on the Serialized Form page for BitSet includes:
Class java.util.BitSet extends Object implements Serializable
Object should not be present. There are many other examples on the Serialized Form page that include "extends Object". Obviously every class is a descendant of Object, but Object itself does not appear in the serialized bytestream, so "extends Object" shouldn't appear on the Serialized Form page.
- relates to
-
JDK-8026220 javadoc leaking package-private types into serialized-form.html
-
- Closed
-