[jdom-interest] serialVersionUID

[Peter V. Gadjokov]

Actually the point of setting the serialVersionUID is to say 'do not compute
one for me' to the serialization mechanism. One is computed automagically
for all classes that do not explicitly set one so if you wanted it to change
when non-compatible changes are made, you might as well leave things as they
are. Setting it explicitly in the class is an indication that the class will
deal with changes on its own (since the normal serialVersionUID computation
is quite draconian - adding a new public method or changing an existing
method to final would break serialization by producing a new
serialVersionUID). If JDOM classes wanted to support stable long
term-serialization in a solid way, several changes need to be made, in
particular, classes should handle their serialization explicitly and
generally avoid shortcuts like 'defaultWriteObject'. Transient members
should still be used for documentation purposes. An implementation would
look something like this - 

public class Element implements Serializable, ...
{
    private static final long serialVersionUID = -342323242344L;

    private static final JDOM_ELEM_SERIALVER = 1;

    // Serialized fields
    protected String name;
    protected List attributes;
    protected List content;

    protected transient Namespace namespace;
    protected transient Element   parent;
    protected transient boolean   isRootElement;
    private   transient String    textualContent;
    private   transient String    trimmedContent;
 
  [...]

private void writeObject(ObjectOutputStream out) throws IOException
{
    out.writeInt(JDOM_ELEM_SERIALVER);
    out.writeString(name);
    out.writeObject(attributes);
    out.writeObject(content);
    out.writeObject(namespace.getPrefix());
    out.writeObject(namespace.getURI());
}

private Object readObject(ObjectInputStream in) throws IOException,...
{
    int mySerialVer = in.readInt();
    if (mySerialVer == JDOM_ELEM_SERIALVER)
    {
        // read name, attributes, content
        // loop over child elements, set parent on all children
    }
    else if (//deal with older arch ....
    {
       [...]
    }
    else
       throw new StreamCorruptedException();
}


Now, that's obviously more work to put in and maintain than relying on
default serialization - but I think just about all of this is required to
achieve managable long-term persistence. the JDOM_ELEM_SERIALVER is an
additional constant the class uses to distinguish between different,
backward compatible serialization versions - this is not something
serialVersionUID supports, there are only two options there - the versions
matches and you read or it doesnt and you fail; in order to get backward
compatability for old archives, one has to maintain explicit externalization
methods. Note that parents are not serialized and neither is isRootElement
(something that should be tracked and set by Documents serialization
methods). 

If we want to go that route, I can whip these it out fairly quickly and
submit a patch.


-pvg

-----Original Message-----
From: Jason Hunter [mailto:jhunter at collab.net]
Sent: Wednesday, September 13, 2000 11:59 AM
To: Jeremiah Jahn
Cc: jdom interest
Subject: Re: [jdom-interest] serialVersionUID


> I think it is completely safe to stamp the above classes 
> ( except namespace of course) with a SVID.

OK, but let's be clear on the benefit we gain.  Per
http://java.sun.com/j2se/1.3/docs/guide/serialization/spec/version.doc.html
it seems the SUID is a hash of the class name, fields, and methods.  So
if the methods are subject to change but not the variables then it's a
good idea to fix the SUID so serialization can occur between different
versions of the class that hold the same variable data.

Now, what happens when we add or remove a variable?  From 
http://java.sun.com/j2se/1.3/docs/guide/serialization/spec/version.doc7.html
it looks like an added field will have its value set to the default on
deserialization of an old version, which will probably break the class. 
So at that point we'd have to manually regen the SUID.  A deleted field
(less likely in JDOM) would be ignored on deserialization of an old
version and that's just fine.

So is the proposal to assign the SUID now for beta5 with a note to
update it should we ever add a variable or perform any other action
listed at
http://java.sun.com/j2se/1.3/docs/guide/serialization/spec/version.doc7.html
?

-jh-
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com