<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Well, that's a strong argument.... ;-)<br>
<br>
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...<br>
<br>
I know of at least one broken mechanism in JDOM at the moment, and I
reopened issue #47...<br>
<br>
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.<br>
<br>
The first step will be writing the tests for it....<br>
<br>
... and it would be useful to keep getting ideas of where JDOM
serialization is used.<br>
<br>
The more specific questions that need answers are:<br>
<br>
Apart from the core JDOM classes (Document, Element, Text, CDATA,
...) what else would need to be serialized?<br>
<br>
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...<br>
<br>
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.<br>
<br>
Namespace is not serializable.... but the EJB argument indicates it
should be.<br>
<br>
What about things like SAXBuilders, XMLOutputters... does the
EJB-type logic apply to that? I think not.<br>
<br>
<br>
My instinct is that the core JDOM values should be the limit of what
should be serializable.<br>
<br>
Additionally, the mechanism used needs to be convenient for
sub-classers to incorporate. The literature is somewhat scarce on
this...<br>
<br>
Is there someone willing and able to take a look at the JDOM
serialization process? What are the gotcha's? Suggestions?<br>
<br>
Rolf<br>
<br>
<br>
On 12/02/2012 8:12 PM, Joe Bowbeer wrote:
<blockquote
cite="mid:CAHzJPEpj5CG2V=dO0sKL8PG-Ut4Y9YHP_zeB=erNOAh3Hp==Cg@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
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>
</div>
</blockquote>
....<br>
</body>
</html>