[jdom-interest] TODO serialization [eg]

Joseph Bowbeer jozart at csi.com
Tue Apr 17 16:37:36 PDT 2001


Summarizing, we have three choices concerning Serialization:

A. Serializable or not?  For how long?

1. Don't implement Serializable, but provide a protected no-arg constructor
to aid subclasses that do wish to implement it.

2. Implement Serializable, but only support short-term persistence.  (In
other words, do roughly what we're doing now.)

3. Implement Serializable (or Externalizable?) using a custom serialized
form that provides long-term persistence.


I like option 1 or 3.  (I don't like option 2 because I think that
implementing Serializable only for short term persistence is too weak.)


B. Serializable or Externalizable?

Option 3 itself involves a choice about how we implement the custom format.
Do we implement Serializable or Externalizable?

I prefer Serializable because it gives us the ability to create a slick
custom serialized form (as Dennis describes), but does not place any burden
on subclasses.

That is, if we implement Serializable/writeObject as I described (and Josh
prescribes), then short-term serialization of subclasses will "just work".
The implicit defaultWriteObject invocation in the subclass in combination
with the custom writeObject implementation in our superclass will do the
trick.

( Dennis is right: defaultWriteObject in the superclass has no effect on the
subclass serialization.  But there is an implicit defaultWriteObject
invocation in every Serializable subclass -- unless writeObject is
explicitly overridden. )

Externalizable is less friendly to subclasses because it does nothing for
them by default.  Note that Externalizable extends Serializable.  Therefore,
once a superclass is Externalizable, no subclass can ever be merely
Serializable.

In other words, if a subclass of an Externalizable superclass wants to
serialize any of its fields, it *must* implement a public writeExternal
method.  (Contrast this to a subclass of a Serializable superclass, which
may not have any extra work to do.)


----- 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 1:20 PM
Subject: Re: [jdom-interest] TODO serialization [eg]

Joseph Bowbeer wrote:

> 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.

ObjectOutput includes writeObject and extends DataOutput, which defines
writeInt and the rest. defaultWriteObject is a special method that may only
be called from within the writeObject method of the class being serialized,
so it doesn't apply in this case. The whole point of Externalizable is that
you control the form of the serialized output, nothing is written by
default.

> > 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").

These are the tradeoffs involved; Externalizable allows much more efficient
serialization, but works best for transport purposes, not for long-term
persistence. I agree with the earlier point that long-term persistence is
best done as an XML document; why define a new format when what you've got
is just an internal representation of an external form already?

Actually, though, I think subclasses could be lazy and just implement
Serializable to have everything work automatically; I believe serialization
still uses writeExternal/readExternal when it's handling the superclass.

  - Dennis














More information about the jdom-interest mailing list