[jdom-interest] XML document transfer performance
jozart at csi.com
Mon Oct 1 12:27:06 PDT 2001
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:
"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
fine to use between different versions of JDOM (or between JDOM and one of
other models, since it doesn't use model-specific information), but for
persistence you'd probably still want to have standard Java serialization
One example is a user subclassing the objects and adding associated
Standard serialization handles this, but XMLS does not because it's purely
XML document representation. Other issues would include things such as
DTD/schema information to the document representation.
It'd be better to make XMLS usable for Java serialization without
the option of default serialization. I think this can be done pretty easily
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
document. I'll add this type of wrapper to the .9 release, due out at the
Even easier, from the user standpoint, would be to add an XMLSDocument
of Document. This does the same thing as XMLSWrapper, but does it
- 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
wanted to use XMLS.
I'll add a section on plans for the next release to the site tonight. If
enough interest I'll move the project to SourceForge where there can be more
discussions and parallel development.
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
> people should be using anything besides standard XML files for long-term
> persistence, but as Jason pointed out, we do need to let different
> of JDOM talk to each other via RMI.)
More information about the jdom-interest