JDOM Extension for Java Object (de)serialization 2006-01-25 - By Matthias Basler
Back
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@(protected)
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ------
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@(protected)
|
|
