[jdom-interest] Re: TODO serialization [eg]

[Dennis Sosnoski]

I'd suggest instead that the focus should be on time and space efficient
serialization for transport. This is not one of the choices in your list, but I
believe it's the most important issue. I know of applications using JDOM to
return results from EJBs, for instance, where communication between components
requires serialization.

Does anyone have a JDOM application where XML is not suitable as a long-term
persistence format?

Using Externalizable vs Serializable with custom readObject and writeObject
methods is a fairly minor distinction - personally I prefer the former, and it's
slightly lower overhead, but I don't see this as a huge concern. You're right on
Externalizable requiring subclasses to implement the methods for themselves if
they want to add anything to the serialized form of the superclass, though, so
the custom readObject and writeObject approach does seem much friendlier for
subclassing.

  - Dennis

Joseph Bowbeer wrote:

> 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