Re: Serialization

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.

On Sun, Feb 12, 2012 at 3:13 PM, Rolf Lear <[email protected]> wrote:

> Hi all.
>
> 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...
>
> 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:
>
> 1. we rely on a hodge-podge of serialization mechanisms to implement it.
> 2. we mark 'Filter' and all the Filter subclasses as being serializable,
> why?
> 3. We have no control of how any sublcasses of our classes implement
> serialization.
>
> Fundamentally, XML is specifically designed to make serialization of
> information easy....
>
> 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?
>
> So, it is my (currently) uninformed opinion that we should strip the
> Serialization from JDOM entirely.
>
> 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....
>
> 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.
>
> So, I am looking for feedback....
>
> does anyone use Java Serialization on JDOM objects?
>
> Why?
>
> Examples?
>
>
>
> Thanks
>
> Rolf
> ______________________________**_________________
> To control your jdom-interest membership:
> http://www.jdom.org/mailman/**options/jdom-interest/**
> [email protected]<http://www.jdom.org/mailman/options/jdom-interest/[email protected]>
>

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