[jdom-interest] serialVersionUID

[Peter V. Gadjokov]

>Well, there's one important benefit to the simple model.  If our
>internal data structures don't change but our public interfaces do
>(because we add new setters and such), then by assigning an sVUID we
>gain what could be called "short-term compatibility", that is
>compatibility until the variables change.

That's true, changing the svUID would work for this purpose and is simple in
implementation. At the same time, it's quite fragile - there is no way to
recover from trivial mistakes in the serialized form parameters
(declarations of transient, etc) without breaking existing archives that
have 'suffered innocently'. For instance, if a svUID were added to element
now, it would have to be changed the moment it is decided persisting the
cached text content is overkill (both relevant ivars are declared
non-transient right now). 

Perhaps it's useful to define three types of persistence lifespan and figure
out which one is best for JDOM. 

 - short term: as it is now, no svUIDs, useful for short-term persistence
and RMI. no guarantee of serialization format compatibility between JDOM
releases. 
  - 'medium term': as described by Jason above. most likely compatible
between minor revisions when no internal structures change and no serialized
classes, whether public or internal are refactored. 
  - long term:, as outlined in my initial post. Compatibility is explicitly
guaranteed between particular (possibly even major) releases. 

Is the effort to implement/support any of these significantly different? I
think they actually end up being about equally easy (or hard). There is no
getting away from explicit serialization methods, even in the short-term
case - the current implementation of Element, for instance, already has such
methods to deal with Namespace serialization. We're not really supporting
the RMI scenario very well yet since parents are implicitly  serialized
which makes it quite expensive to send over a single deep leaf element over
RMI. I'd say the implementation/maintenance cost is comparable for all
three, the last one being a bit more work in implementation and the first
two being somewhat more difficult to maintain well - their automatic nature
automates both good and bad serialized forms with equal ease. 

>Is serialization important as long-term storage?  
>Or should we just tell people to use *XML* as long term storage 
>(a very reasonable alternative)?

XML is a reasonable alternative although it is arguably more of an
orthogonal feature than alternative. A few of the obvious differences are: 

 A serialized archive contains enough information to exactly re-create a
serialized object graph - this is harder to do with XML, depending on output
options and other factors, the objects->xml and xml->objects operations
might not be idempotent.
 Java serialization is the 'native' serialization mechanism, the only one
supported by other core APIs, such as RMI and APIs based on RMI such as EJB,
Jini, etc (this might not be important for long term serialization but just
supporting RMI well requires about as much forethought and tweaking as
long-term serialization)
  The Java serialization facility supports storage formats other than the
built-in binary format - including XML, several XML-capable
Object(Output|Input)Stream implementations already exist. This would cover
the needs of those who want the format to be XML, but not necessarily the
XML that the Document actually represents. 
  The binary serialized format is probably smaller and almost certainly
faster to read/write/'parse'(*). This can be useful when storing JDOM XML
documents in, say, an RDBMS - one can store documents as smaller, more
efficiently read/written BLOBs. 

(*) I'll try to send out some informal numbers on this soon. 

In a word, I think it's worth supporting, but it's certainly a
'nice-to-have', it has more to do with JDOM being a good 'java citizen' as
opposed to processing XML, its primary purpose. 
   
>BTW, do any DOM impls support long-term serialization, or 
>would this be another JDOM extra?

I don't know of any that do but I haven't looked very carefully. Good
support for long-term serialization is fairly rare in general. It's
typically important in container classes and component assemblers/builders.
With the collections package covering most container class needs and
code-generation being the more fashionable choice for builders, the
automatic serialization mechanism is the most common choice. 

-pvg