[jdom-interest] JDOM Extension for Java Object (de)serialization

William Krick wkrick at eio-online.com
Wed Jan 25 14:19:23 PST 2006

I'm not positive but I think that WDDX was created to address the problem of
XML serialization of Java objects.  You should give it a look...

-----Original Message-----
From: Matthias Basler [mailto:Matthias.Basler at uni-jena.de]
Sent: Wednesday, January 25, 2006 3:23 PM
To: jdom-interest at jdom.org
Subject: [jdom-interest] JDOM Extension for Java Object

Hi developers, again

My second question touches one of the few "weak points" of JDOM - and DOM in
general. It is clear to me that the philosophy of any DOM model is to have
complete model in memory, f.e. in order to edit it. Of course this is
problematic when the files (and models) reach a certain size.

As said, I have reviewed several other APIs like Sax, Stax and GTXML, each
which solves this problem in another way, introducing other constraints.

I was (and am) looking for an API that allows to easily serialize and
deserialize between XML files and Java object trees. Not DOM objects, but
specific, meaningful Java objects. I have as a test case the classes of
"Chapter, "Paragraph", "Title" and "Author" and an XML file describing such
book. It wasn't a big problem to read this file with JDOM and convert the
created  JDOM Elements to their corresponding classes and build a "Book".
other way round wasn't a problem either.

However I felt that these both tasks could be done without keeping the
JDOM model in memory. (Note that I did not edit the JDOM model, searched
through it or did any other thing that would require the whole DOM model.)
Since I found Sax not very "attractive", I started looking for a solution
above tasks that was JDOM based and still wouldn't require a complete model

I did find such solution for both directions. When reading from file any
finished JDOM object is instantly converted to it's Java object counterpart
(e.g. "Paragraph") and then removed from the tree. So you end up with a
empty document, but a complete Book object (or whatever is described by the
document). When writing I use "deferred Elements" (i.e. Proxies) which are
filled with content only when needed and are - again - destroyed after
been written to the file. Some quick tests showed that the memory
footprint is drastically(!) reduced, depending of course on the structure of
XML document.

The nice point is that I only need 7 lightweight classes to do all this,
I let JDOM do all the relevant tasks like file parsing and writing. I didn't
even have to copy existing code.  Some other quick facts:
- I use no validation (DTD or XML Schema), but the Java classes (Book,
whatever) can be easily be written to take over this job.
- My API does not hide any complexity of XML. In principle, everything
possible in JDOM is possible in my API as well. F.e. namespaces are
(but not yet tested).

Personally I don't like the idea of creating "just" another separate project
JAR only to distribute 7 small classes (and a few example classes),
depending on
JDOM. So I'd like to know if there is interest to
a) review the code
b) possibly improve it and
c) make it part of the "jdom-contrib" jar for a release.

You have a lot more experience with your API and could maybe improve
speed and memory load even further.

Is there interest? Let me know.

Matthias Basler
c9bama at uni-jena.de

This mail was sent through http://webmail.uni-jena.de
To control your jdom-interest membership:

More information about the jdom-interest mailing list