[jdom-interest] TODO serialization [eg]

[philip.nelson at omniresources.com]

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.

> -----Original Message-----
> From: Joseph Bowbeer [mailto:jozart at csi.com]
> Sent: Saturday, April 14, 2001 6:22 AM
> To: jdom-interest at jdom.org
> Subject: [jdom-interest] TODO serialization [eg]
> 
> 
> There is a "serialization" item in the TODO list already.  
> This information
> supplements that item.
> 
> 0. Do we really want to make the JDOM classes Serializable?  
> It's a lot of
> work to do this right and then to maintain it (see below).  
> Just checking...
> 
> 1. serialVersionUID.  We should add explicit serialVersionUID 
> definitions.
> 
> 2. Custom serialized form.  We should create a custom 
> serialized form rather
> than using the default serialized form.  The default 
> serialized form is
> generally a bad choice (except for simple "data" classes) 
> because it allows
> the implementation details to leak-out into the public.  
> Therefore it's
> usually best to declare every field transient and code your own custom
> serialized form.  In addition to hiding implementation 
> details, a custom
> serialized form can be more efficient in both space and time.
> 
> 3. Document @serial and @serialData.  Every non-transient field should
> include a @serial javadoc comment.  This applies to private 
> fields as well.
> (Effective Java says: "That is because these private fields 
> define a public
> API, the serialized form, and this public API must be documented."
> 
> Similarly, the writeObject method should include a @serialData comment
> describing the serialized form.
> 
> 4. Overridable.  As was mentioned in the message about subclassing,
> readObject should not invoke any overridable methods.
> 
> --
> Joe Bowbeer
> 
> 
> 
> 
> 
> 
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/yo
uraddr at yourhost.com