Skip to Content.
Sympa Menu

xom-interest - [XOM-interest] Re: Serializing objects that contain an instan ce of nu.xom.Document, part II

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Wolfgang Hoschek <whoschek AT lbl.gov>
  • To: xom-interest AT lists.ibiblio.org
  • Subject: [XOM-interest] Re: Serializing objects that contain an instan ce of nu.xom.Document, part II
  • Date: Fri, 20 Feb 2004 10:26:44 -0800

The people asking for Java serialization probably don't really care about
the above argument. They just want to use XOM as the XML package in an
application that *requires* Java serialization (eg. EJB).

It appears that saying "XOM won't be serializable" is equivalent to saying
"XOM can't be used in EJB". This is perhaps a reasonable thing to say,
perhaps not, but it's almost entirely orthogonal to a discussion of which
serialization method is "better".

That's been said. I've yet to be convinced that statement is true though. I don't know enough about EJB to judge whether "EJB requires object serialization" is actually a true statement for myself. To convince me, you're going to need a compelling use case, and an EJB expert who confirms that that use-case really does need XOM objects to be Serializable. For instance, you'll need to explain to me why you can't just call toXML and serialize the resulting string. Hell, you coudl even do this in your own subclass that implemented Serializable and provided readObject and writeObject methods (or would it have to implement Externalizable for complete control? I forget.) Either way, that seems like a simple fix for any system that simple doesn't work with serializing XOM objects.

If good reasons were provided, then I would begin to consider whether implementing Serializable was practical. It may not be. But so far, I remain unconvinced it's even useful.

Implementing Java serialization so that it works for long term persistence across xom versions and jdk versions (even across different javac's) is complex, fragile, a pain in the ass and IMHO not worth it.

But people that want/need java serialization typically do not want that anyway (if they'd need it then relational dbs, xml serialization etc. are much better options). Such people typically work in tightly coupled scenarios like the ones outlined by others here before, where versions and upgrades are under control and the same everywhere in their application. Implementing that kind of restricted java serialization is easy: Just add "implements Serializable" to all relevant and dependent classes. If you document in xom that nothing more than that restricted notion of serializable is guaranteed, you should be fine.

This seems a useful compromise to me.

Wolfgang.




  • [XOM-interest] Re: Serializing objects that contain an instan ce of nu.xom.Document, part II, Wolfgang Hoschek, 02/20/2004

Archive powered by MHonArc 2.6.24.

Top of Page