Re: Serialization

Well, that's a strong argument.... ;-)

It was exactly because I was reading Effective Java that I don't want to 
do battle with the serialization at all.... but J2EE will be a somewhat 
deciding factor...

I know of at least one broken mechanism in JDOM at the moment, and I 
reopened issue #47...

I think I will continue to study up on serialization, with a view to 
rewriting the implementation for JDOM2. It is an area of my personal 
experience which is lacking anyway.

The first step will be writing the tests for it....

... and it would be useful to keep getting ideas of where JDOM 
serialization is used.

The more specific questions that need answers are:

Apart from the core JDOM classes (Document, Element, Text, CDATA, ...) 
what else would need to be serialized?

I have already removed the concept of serialization from the new XPath 
API (the JDOM1.x XPath is serializable... but it is broken). Should 
XPaths be serializable? That would be very hard given that XPath 
variables have plain Object values...

I intend to remove the serialization of Filter instances. Is this a 
mistake? Filters are practically constants... and are not likely to be 
passed around. Additionally, if a user requires serialization they can 
easily extend a filter for their own purposes.

Namespace is not serializable.... but the EJB argument indicates it 
should be.

What about things like SAXBuilders, XMLOutputters... does the EJB-type 
logic apply to that? I think not.


My instinct is that the core JDOM values should be the limit of what 
should be serializable.

Additionally, the mechanism used needs to be convenient for sub-classers 
to incorporate. The literature is somewhat scarce on this...

Is there someone willing and able to take a look at the JDOM 
serialization process? What are the gotcha's? Suggestions?

Rolf


On 12/02/2012 8:12 PM, Joe Bowbeer wrote:
> The Serialization chapter in Effective Java, 2nd Ed. is worth 
> reviewing.  It suggests careful thought before declaring that 
> something is Serializable.
>
> Unfortunately, the need for Serializable objects in J2EE argues the 
> other way.  As Andrew Jenkins explained a few years ago:
>
> "Every object that is stored in an HttpSession or reachable by an
> object in an HttpSession must be serializable.  Every argument in an EJBs
> interface or reachable by an argument must be serializable.  As a hack 
> when
> some class was distantly reachable by an EJB argument, I have taken the
> approach in the past of declaring the class as serializable, marking
> important but non-serializable fields as transient, and allowing the 
> object
> to be serialized, knowing that if it were deserialized it would be in a
> broken state due to missing members.  This is easier than enforcing 
> that all
> clients declare their instances of the class transient.  Some of our 
> classes
> get around this by having a public refresh(non-serializable field1,
> non-serializable field2,...) method that needs to be invoked by the client
> anytime serialization may have occurred."
>
> Arguments/needs such as this is what led to a proliferation of 
> Serializable classes in java.util.concurrent:
>
> http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/package-tree.html 
>
>
> Semaphore, concurrent Queue implementations and ForkJoinTask are 
> Serializable, in addition to the concurrent collections.  This was not 
> easy to get right (even for Doug Lea).
>
> So I suggest you think about the users of JDOM in J2EE before deciding.
....

_______________________________________________
To control your jdom-interest membership:
http://www.jdom.org/mailman/options/jdom-interest/[email protected]