[jdom-interest] XML document transfer performance

[Joseph Bowbeer]

Dennis Sosnoski wrote:

> It'd be better to make XMLS usable for Java serialization without
> eliminating the option of default serialization.

I suspect that using Java's default serialization for XML document objects
will be incredibly slow and apt to stack overflow.  Also, because it exposes
the internals of the implementation, it won't support transmission between
independent JDOM implementations -- unless the entire implementation becomes
part of the specification.

So I think some efficient, implementation-independent serialized format is
desirable.  (Something similar to your format?)

By the way, I remember we had a discussion a while back concerning whether
JDOM objects should be Serializable or Externalizable:

  http://www.servlets.com/archive/servlet/ReadMsg?msgId=7697

  "Externalizable is less work for us and has less overhead.  Serializable
is more work for us (e.g., marking all the fields transient), but is also
more extensible (via defaultWriteObject) and is friendlier to subclassers.
...  I favor Serializable."


--- original message ---

From: Dennis Sosnoski dms at sosnoski.com
Date: Mon, 01 Oct 2001 09:42:12 -0700

XMLS is more designed for document transfer than for persistence. It should
be
fine to use between different versions of JDOM (or between JDOM and one of
the
other models, since it doesn't use model-specific information), but for
general
persistence you'd probably still want to have standard Java serialization
supported.

One example is a user subclassing the objects and adding associated
information.
Standard serialization handles this, but XMLS does not because it's purely
an
XML document representation. Other issues would include things such as
adding
DTD/schema information to the document representation.

It'd be better to make XMLS usable for Java serialization without
eliminating
the option of default serialization. I think this can be done pretty easily
by
using a wrapper class: XMLSWrapper is given an instance of Document (or
Element), and implements Externalizable. When XMLSWrapper is serialized it
generates XMLS for the document, and when restored it reads XMLS to rebuild
the
document. I'll add this type of wrapper to the .9 release, due out at the
end of
October.

Even easier, from the user standpoint, would be to add an XMLSDocument
subtype
of Document. This does the same thing as XMLSWrapper, but does it
transparently
- if you create an XMLSDocument you'll *always* use XMLS for serialization.
Users who want to be able to use default serialization instead just use the
normal Document. The wrapper alternative would still be possible for when
they
wanted to use XMLS.

I'll add a section on plans for the next release to the site tonight. If
there's
enough interest I'll move the project to SourceForge where there can be more
discussions and parallel development.

  - Dennis

Alex Rosen wrote:

> This looks very cool! It's nice to see support for both dom4j and JDOM.
>
> I wonder if this could be JDOM's native serialization format? What do you
> think about the long-term compatibility of this format? (I don't think
that
> people should be using anything besides standard XML files for long-term
> persistence, but as Jason pointed out, we do need to let different
versions
> of JDOM talk to each other via RMI.)
>
> Alex