JDK-4094702 : Need more control over Externalizable stream headers
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.io:serialization
  • Affected Version: 1.1.4
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: solaris_2.6
  • CPU: x86
  • Submitted: 1997-11-21
  • Updated: 1997-11-24
  • Resolved: 1997-11-24
Description

Name: rm29839			Date: 11/21/97


One of the good things about using the Externalizable interface
over the Serializable interface is that with the former it is
possible to control the layout of the data stream that represents
the stored object.

An Externalizable class should therefore be able to handle data
streams written from previous versions of itself.

Many people documenting Externalizable say that this is possible.

In fact, however, it does not seem to be.  This is because the
Externalizable classes have the same header added to the front of
them as Serializable ones.  This header is created by the
ObjectStreamClass for all Serializable (therefore also
Externalizable) objects.

This means that when I write my version number out from my
Externalizable class I am not doing anything useful.  Because if
I ever change my class (insofaras I add/delete public fields
or methods) I will not be able to read the streams from the
older version of the object because the hash code based on the
fields etc,. will have changed.

I will be able to read only the streams created by the new 
version of the class.

What I would like is for there to be a new interface.
People wanting the kind of control I describe could then
implement this interface as well as the Externalizable interface,
or else instead of it.  If this interface were called
Versionizable.  An object that was Versionizable would have no 
version number written out in the header at all.

Versionizable could extend Externalizable.

But a header would still be written to hold the class name
and so the readObject system would still work with it.

Also, from Bug ID 4054452, you could also have another
interface that resulted in no header being written to
the object stream at all.  I'm not sure how you would read
such an object back in, but there you are.

I am reporting this because it has stopped me from using 
the Externalizable interface and I have had to implement my
own way of doing the same thing.  I may be missing something
here but I not sure.

Thanks.
(Review ID: 20440)
======================================================================

Comments
WORK AROUND Name: rm29839 Date: 11/21/97 ======================================================================
11-06-2004

EVALUATION Even through a class is Externalizable, one still has to add a serialVersionUID member to the class to indicate even though the interface to the class has changed, it is still compatible as far as the serialized or externalized form of the class. Example member stream unique identifier to a class: static final long serialVersionUID = 3487495895819393L; See http://java.sun.com/products/jdk/1.2/docs/guide/serialization/spec/class.doc4.html#5139 for a description of the serialVersionUID. and http://java.sun.com/products/jdk/1.2/docs/guide/serialization/spec/class.doc3.html#5023 on how to generate a serialVersionUID. If one wishes to simply disable this feature for Externalizable, we do not recommend this approach, you can just declare all serialVersionUID members of externalizable classes to be some non-zero constant number. joseph.fialli@East 1997-11-24
24-11-1997

PUBLIC COMMENTS Even through a class is Externalizable, one still has to add a serialVersionUID member to the class to indicate even though the interface to the class has changed, it is still compatible as far as the serialized or externalized form of the class. Example member stream unique identifier to a class: static final long serialVersionUID = 3487495895819393L; See http://java.sun.com/products/jdk/1.2/docs/guide/serialization/spec/class.doc4.html#5139 for a description of the serialVersionUID. and http://java.sun.com/products/jdk/1.2/docs/guide/serialization/spec/class.doc3.html#5023 on how to generate a serialVersionUID. joseph.fialli@East 1997-11-24
24-11-1997