XOM API for Processing XML with Java

["Steve Loughran" <steve.loughran AT gmail.com>]

On Dec 10, 2007 1:40 AM, Tatu Saloranta <cowtowncoder AT yahoo.com> wrote:
> --- Steve Loughran <steve.loughran AT gmail.com> wrote:
>
> > On Dec 5, 2007 11:39 AM, Michael Kay
> > <mike AT saxonica.com> wrote:
> ...
> > > But the best way to serialize a tree
> > representation of an XML document is as
> > > XML. So Java serialization really isn't
> > appropriate.
> >
> > Putting aside technical and idelogical purity,
> > sometimes its good to
> > serialize document trees, as that way you can
> > marshall it over RMI
> > with ease
> >
> > (a) use JDom; this is a supported use case
> >
> > (b) subclass nu.xom.Document, implement
> > serialize/deserialize code
> > that saves the doc to a UTF8 encoding in a byte
> > array, and sends that
> > over the wire, converting it at the far end .
>
> While this is certainly possible, the question is, why
> bother? Serialization to textual xml can be done in
> couple of lines of code and results in a byte array
> (directly or via ByteArrayOutputStream) easily
> transmittable using normal methods, be that sending
> via sockets, or even sending over RMI as a byte array.
>
> This method is unlikely to be slower end-to-end than
> object-serialization alternatives, given how fast xml
> parsing and serialization is, and the overhead of
> default Java object serialization.
>

I'm not going to defend Java Serialisation overhead, it is pretty slow
because it has to remember everything else that was sent and check for
duplicates. It's sending a graph over, not a tree, after all.

But there are a lot of places where it gets used, such as saving
session state in an app server, or chatting between processes in
EJB-land. Sometimes the things you send over dont care what is
included in the conversation, as long as you can add them to types
like HashMap<String,Serializable>.  Being able to seamlessly pump xom
docs over these channels is convenient, and, like I said, you could
probably hack a subclass of Document to serialize via a byte array.
What you lose there is the guarantee that the far end will see the
same instance types in the tree as you had before, as of course, you
may reparse it with a different element factory. That is not
necessarily a bad thing, just a fact of life. Anyone who has seen RMI
raise unmarshall exceptions trying to unmarshall an exception will be
aware of the limitations of the java RMI/serialisation world view -you
either get the type you had before, or an error- and the consequences
-you get an excepion telling you something went wrong at the far end,
but no way of knowing what. Even SOAPFaults are more useful.

-steve