alek blogs

Comparing XB1 to JDOM ...

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 ..)

created Wed July 30, 2003 8:06 PM EST [2003/7/30 20:6 EST] permalink

This blog is about:
XML, Java, and everything else (or nothing ..)

Find more about
blog author

Blogroll:
Sam Ruby
Russell Beattie
Diego Doval
Joel on Software
and some (almost) harmless entertainment: The BileBlog

Projects::
MicroLogger
Xydra
WSIF
XmlPull API
XPP3/MXP1
XSOAP
XMessages

RSS
0.92 [validate]
2.0 [validate]

Filter Entries:
Life
Java
XML
Computing
Web Services