[jdom-interest] TODO serialization [eg]

[Joseph Bowbeer]

Joe Bowbeer writes:

> > 2. Custom serialized form.  We should create a custom
> > serialized form rather than using the default serialized form.

Philip Nelson writes:

> What would you optimize #2 for? space? speed?

I'm not too concerned with optimization, although I understand that the
default serialized form can be prone to stack overflow...

I'm mostly concerned with defining a standard and hiding implementation.

If we intend to support *long-term* serialization and we rely on the default
serialized form, then many details of our initial implementation will become
part of the JDOM standard.

For example, suppose Element contains the following declaration:

    private List content;

Since this field is non-transient, it will be serialized by
defaultWriteObject.  When this field is serialized, its current
implementation is serialized.  Meaning that if we're using SinglyLinkedList
as our List representation, then we'll always have to support
SinglyLinkedList because it will live-on in serialized Elements.

Hiding the implementation from the serialized form is a matter of declaring
most if not all fields transient and adding some custom code to the
readObject and writeObject methods.

For example:

    private transient List content;

    private synchronized void writeObject(s) throws IOException {
        s.defaultWriteObject();
        // Write out content length.
        s.writeInt( content.size() );
        // Write out all content in the proper order.
        for (Iterator i = content.iterator(); i.hasNext(); )
            s.writeObject( i.next() );
        // etc...
    }

    private synchronized void readObject(s)
    throws IOException, ClassNotFoundException {
        s.defaultReadObject();
        // Read in content length.
        int size = s.readInt();
        // Read in all content in the proper order.
        content = new SinglyLinkedList();
        for (int i = 0; i < size; i++)
            content.add( s.readObject() );
        // etc...
    }

By the way, even when defining a custom serialized form, it's supposed to be
a good idea to continue to call defaultWriteObject and defaultReadObject.

Quoting once again from Effective Java:

    "The resulting serialized form makes it possible to add non-transient
fields in a later release while preserving backward and forward
compatibility.  If an instance is serialized in a later version and
deserialized in an earlier version, the added fields will be ignored."


Note:  I wasn't aware of most of this stuff until I reviewed the book, but
now that I am aware (darn!), I think these are legitimate issues that we
should all be aware of.


----- Original Message -----
From: <philip.nelson at omniresources.com>
To: <jozart at csi.com>; <jdom-interest at jdom.org>
Sent: Monday, April 16, 2001 7:05 PM
Subject: RE: [jdom-interest] TODO serialization [eg]

I think your suggestions 1 and 3 are good.  Number four you have already
addressed in subclassing todos.

What would you optimize #2 for? space? speed?  There was once an argument to
make xml the serialization format.  I think the use case for serialzation is
not so strong as to spend tremendous amounts of time on it.  Why would we
want to hide the implementation details in the serialization format (just
asking).

I like the idea of serialization in JDOM.  I've outlined some reasons in the
past.  Note that PartialList was not serializable because of an error.  I
think FilterList should be serializable because the common implementations
of List are serializable.