<div><font color="#222222" face="arial, sans-serif">The Serialization chapter in Effective Java, 2nd Ed. is worth reviewing.  It suggests careful thought before declaring that something is Serializable.</font></div><div><font color="#222222" face="arial, sans-serif"><br>


</font></div><div><font color="#222222" face="arial, sans-serif">Unfortunately, the need for Serializable objects in J2EE argues the other way.  As Andrew Jenkins explained a few years ago:</font></div><div><br></div><span>"Every object that is stored in an HttpSession or reachable by an</span><br>

<span>object in an HttpSession must be </span><span>serializable</span><span>.  Every argument in an EJBs</span><br>
<span>interface or reachable by an argument must be </span><span>serializable</span><span>.  As a hack when</span><br><span>some class was distantly reachable by an EJB argument, I have taken the</span><br>
<span>approach in the past of declaring the class as </span><span>serializable</span><span>, marking</span><br><span>important but non-</span><span>serializable</span><span> fields as transient, and allowing the object</span><br>


<span>to be serialized, knowing that if it were deserialized it would be in a</span><br><span>broken state due to missing members.  This is easier than enforcing that all</span><br><span>clients declare their instances of the class transient.  Some of our classes</span><br>


<span>get around this by having a public refresh(non-</span><span>serializable</span><span> field1,</span><br><span>non-</span><span>serializable</span><span> field2,...) method that needs to be invoked by the client</span><br>


<span>anytime serialization may have occurred."</span><div><br></div><div>Arguments/needs such as this is what led to a proliferation of Serializable classes in java.util.concurrent:</div><div><br></div><div><a href="http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/package-tree.html" target="_blank">http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/package-tree.html</a>
</div><div><br></div><div>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).</div><div><br></div>

<div>So I suggest you think about the users of JDOM in J2EE before deciding.<br><br><div class="gmail_quote">On Sun, Feb 12, 2012 at 3:13 PM, Rolf Lear <span dir="ltr"><<a href="mailto:jdom@tuis.net" target="_blank">jdom@tuis.net</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all.<br>
<br>
I have only limited experience with Java serialization. My experiences in the past have always been ugly, but I have never been expert enough in it to be opinionated...<br>
<br>
I have been trying to remedy that now, though, and I have come to the conclusion that JDOM still has broken serialization. The problems I see are:<br>
<br>
1. we rely on a hodge-podge of serialization mechanisms to implement it.<br>
2. we mark 'Filter' and all the Filter subclasses as being serializable, why?<br>
3. We have no control of how any sublcasses of our classes implement serialization.<br>
<br>
Fundamentally, XML is specifically designed to make serialization of information easy....<br>
<br>
The whole purpose of JDOM is to make it easy to serialize and deserialize (and inspect and change) XML. Why are we also implementing native Java serialization?<br>
<br>
So, it is my (currently) uninformed opinion that we should strip the Serialization from JDOM entirely.<br>
<br>
If people can find convincing reasons to make JDOM serializable, it is my opinion that it should be implemented as a simple call to XMLOutputter.output(....) to convert the JDOM to a stream (and a reverse ability to parse the results....). This will satisfy any subclassing mechanisms....<br>



<br>
Finally, if there is a convincing reason why that would be inappropriate too, then I think the right answer would be to replace the current serialization process with a redesigned and more robust one.<br>
<br>
So, I am looking for feedback....<br>
<br>
does anyone use Java Serialization on JDOM objects?<br>
<br>
Why?<br>
<br>
Examples?<br>
<br>
<br>
<br>
Thanks<br>
<br>
Rolf<br>
______________________________<u></u>_________________<br>
To control your jdom-interest membership:<br>
<a href="http://www.jdom.org/mailman/options/jdom-interest/youraddr@yourhost.com" target="_blank">http://www.jdom.org/mailman/<u></u>options/jdom-interest/<u></u>youraddr@yourhost.com</a><br>
</blockquote></div><br>
</div>