[jdom-interest] TODO serialization [eg]

[Joseph Bowbeer]

Dennis Sosnoski writes:

> I don't know where you saw the reference to PDF or such,
> Joe, but this isn't true - when Externalizable is implemented
> by a class the class identifier is still written and read by the
> serialization code, but the class writeExternal/readExternal
> methods are used for everything else. These methods are
> called with the ObjectOutput/ObjectInput instance and can
> use all the standard method supplied by these interfaces.

You must be right.  The XML/PDF reference was here:

Discover the Secrets of Serialization - July 2000
http://developer.java.sun.com/developer/technicalArticles/Programming/

I guess the class identifier is still written and read by
writeObject/readObject before they delegate to the Externalizable
implementation.  If one called writeExternal directly, this wouldn't be the
case, but that's neither here nor there...

Concerning convenience, writeExternal is given an ObjectOutput interface -
not an ObjectOutputStream.  (Or can one assume?)  ObjectOutput doesn't
implement defaultWriteObject.  Nor does it implement writeInt or any of the
many other convenience methods.

> Extending it is no problem - the subclass needs to do it's
> own work in writeExternal, then call the superclass method,
> and reverse the process in readExternal.

Isn't implementing writeObject easier for subclasses?

For example, using writeObject, subclasses only interested in short-term
persistence "will just work" because their non-transient fields will be
serialized automatically by the defaultWriteObject in our superclass
writeObject implementation (right?).

If we go the Externalizable route, on the other hand, we're not giving
subclasses much of an option.

Nor does writeExternal provide the compatibility mechanism that
defaultWriteObject provides (i.e., the ability to add new non-transient
fields in the future and have it "just work").


----- Original Message -----
From: "Dennis Sosnoski" <dms at sosnoski.com>
To: "Joseph Bowbeer" <jozart at csi.com>
Cc: <jdom-interest at jdom.org>
Sent: Tuesday, April 17, 2001 12:22 PM
Subject: Re: [jdom-interest] TODO serialization [eg]

Externalizable is the cleanest way of handling this since it bypasses the
reflection otherwise used by serialization. I don't know where you saw the
reference to PDF or such, Joe, but this isn't true - when Externalizable is
implemented by a class the class identifier is still written and read by the
serialization code, but the class writeExternal/readExternal methods are
used for everything else. These methods are called with the
ObjectOutput/ObjectInput instance and can use all the standard method
supplied by these interfaces.

Extending it is no problem - the subclass needs to do it's own work in
writeExternal, then call the superclass method, and reverse the process in
readExternal.

For best overall performance you'd probably want to write and read names
(elements, attributes, namespaces, etc.) as String objects, using the
writeObject/readObject methods of ObjectOutput/ObjectInput; that way there'd
only be a single copy of the name text in the serialized form, with
references to it when it's reused (this assumes that the name Strings are
reused, which I know at least some parsers do). Attribute values and content
data Strings could be written/read as UTF text (using writeUTF/readUTF) to
avoid the bookkeeping overhead of serialization. This would give a several
times speed improvement for serialization, while also significantly reducing
the serialized form size. It'd also be considerably more compact than the
actual XML.

  - Dennis

Dennis M. Sosnoski
Sosnoski Software Solutions, Inc.
http://www.sosnoski.com

Joseph Bowbeer wrote:

> Alex Rosen writes:
>
> > Isn't that what Externalizable is for?
>
> According to the magic spec, Externalizable is what you'd extend if you
> wanted to use something like PDF or XML as the serialization format.  I
> don't think Externalizable is easy to extend in a subclass (i.e., it's all
> or nothing), but I'm not sure about that.
>
> The writeObject method, on the other hand, is passed an
> ObjectOutputStream, which provides the powerful defaultWriteObject
> extensibility mechanism, as well as a set of convenient write* methods.
>
>   http://java.sun.com/j2se/1.3/docs/guide/serialization/
>
> ----- original message -----
> From: Alex Rosen arosen at silverstream.com
> Date: Tue, 17 Apr 2001 09:59:03 -0400
>
> > 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.
>
> Isn't that what Externalizable is for? That way you don't have to remember
> to make all fields transient. Or is there something in this magic book
> that says that Externalizable is bad? :)
>