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

[William Krick]

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...
http://www.openwddx.org/



-----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
(de)serialization


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
the
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
of
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
really
specific, meaningful Java objects. I have as a test case the classes of
"Book",
"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".
The
other way round wasn't a problem either.

However I felt that these both tasks could be done without keeping the
complete
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
for
above tasks that was JDOM based and still wouldn't require a complete model
in
memory.

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
nearly
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
having
been written to the file. Some quick tests showed that the memory
footprint is drastically(!) reduced, depending of course on the structure of
the
XML document.

The nice point is that I only need 7 lightweight classes to do all this,
since
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,
Chapter,
whatever) can be easily be written to take over this job.
- My API does not hide any complexity of XML. In principle, everything
that's
possible in JDOM is possible in my API as well. F.e. namespaces are
supported
(but not yet tested).

Personally I don't like the idea of creating "just" another separate project
and
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
usability,
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:
http://www.jdom.org/mailman/options/jdom-interest/youraddr@yourhost.com