This is mini review of "A
Design Review of JDOM (A Conversation with Elliotte
Rusty Harold, Part III)".
Let see how Xml Pull Builder a.k.a. XB1 (for more details on XB1 see its
home page) compares to JDOM based on points raised in article.
A Short History of JDOM
Before we do this few word about XB1. XmlPull Builder Version 1 a.k.a. XB1 is
lightweight document object model to represent XML tree that is implemented on
to Common API for XML Pull Parsing and alpha
version is in
XPP3/MXP1.
JDOM Offers Many Convenience Methods
XB1 is currently rather modest API and do not have lot of methods (except for obvious overloading of
methods) and that makes API quite simple (at least for now).
JDOM Allows Malformed Documents
XB1 implementation also allows creation of malformed documents or let put it
this way: the implementation does not do extensive checks but XB1 API allows
implementations that will do those checks (XB1 API is composed of interfaces).
BTW: example with control characters is not good as XML allows to have control
characters but escaped as numerical entities AFAIR ...
JDOM Ignores Setter Method Conventions
I do not see problem here: JDOM is not Java Bean and chaining methods may be
sometimes convenient (but should not be overused). This looks like rather weak
complaint ...
JDOM Uses Java Collections
XB1 goes one step even further and it uses Generics for even more natural
iterators than mentioned NodeList (currently moving to use future java.lang
SimpleIterator interface so
idiomatic for(XmlElement el: node.elements()) will work in JDK 1.5) .
JDOM Uses Too Many Checked Exceptions
XB1 has only one exception (at least for now) and it is runtime exception for
all reasons mentioned in the article and i woould add one more reason:
RuntimeException makes it easier to integrate XB1 into existing code.
Will JDOM Remain Class-Based?
I agree that interface based API is more versatile as it allows to abstract
form implementation and allow creating XML tree models directly from other data
sources that XML event stream from parser (like databases)
Conclusion
I was disappointed that XPath integration (and good performance of it) was
not mentioned. Also I would like to see some tests that compared memory
footprint and how easy is to build partial tree: this is very easy with XML pull
parsing but quite difficult with push parsing (in SAX it requires provide way to
overwrite endElement() callback and in general is as much fun as writing SOAP
deserializer with SAX). And as far as future of XML Tree APIs: I would like to
see how easy is to annotate XML infoset items with additional
information (needs for it emerges with data bindings and PSVI)
But after all what makes and breaks APIs is how programmers feel about them,
and I feel good about XB1 when I am using it (nothing to do with the fact that I am author of it
of course ..)
Previous Topic
