Sponsored Link •
Elliotte Rusty Harold talks with Bill Venners about problems with the JDOM API. Most are general design issues for any Java API: too many convenience methods and checked exceptions, not preventing user mistakes, ignoring conventions.
Elliotte Rusty Harold is a prolific author of numerous books about Java and XML, and creator of the popular Java website Cafe au Lait and XML website Cafe con Leche. He contributed to the development of JDOM, a popular XML processing API for Java. His most recent book, Processing XML with Java, shows how to parse, manipulate, and generate XML from Java applications using several XML APIs, including SAX, DOM, and JDOM.
At a meeting of the New York XML SIG in September, 2002, Harold unveiled an XML processing API of his own design: the XOM (XML Object Model) API. On Cafe au Lait and Cafe con Leche, Harold described XOM like this:
Like DOM, JDOM, dom4j, and ElectricXML, XOM is a read/write API that represents XML documents as trees of nodes. Where XOM diverges from these models is that it strives for absolute correctness and maximum simplicity. XOM is based on more than two years' experience with JDOM development, as well as the last year's effort writing Processing XML with Java. While documenting the various APIs I found lots of things to like and not like about all the APIs, and XOM is my effort to synthesize the best features of the existing APIs while eliminating the worst.
In this interview, which is being published in multiple installments, Elliotte Rusty Harold discusses the strengths and weaknesses of the various XML processing APIs for Java, the design problems with existing APIs, and the design philosophy behind XOM.
Bill Venners: Tell me about JDOM.
Elliotte Rusty Harold: The convention center we're in now, the Santa Clara convention center, is where JDOM was born three years ago at the very first O'Reilly Enterprise Java conference. Brett McLaughlin, who was then working on O'Reilly's Java and XML book, was giving a talk on DOM. Jason Hunter was in the audience. Jason noticed that about every third slide in Brett's talk was "gotcha!" Something in DOM doesn't work like you would naturally expect it to work. So Jason said to himself, there's got to be a better way. He and Brett went outside and had lunch on the lawn, and in the course of their conversation decided to create what would become JDOM. Over the next couple of weeks, they did some work on it, and I think released their first alpha version to the world.
JDOM, like DOM, is a tree-based object model. It loads the whole document in memory like DOM, but it's much simpler. JDOM uses concrete classes rather than interfaces, which DOM uses, and I saw how that made life simpler. JDOM is designed just for Java. It is not designed to support C++, Python, Perl, or any other language. The interoperability is achieved through XML, not the API. The API doesn't need to port. A Java API runs on one system. The XML document is what moves between systems and needs to be portable. JDOM is in many ways what DOM should have been. It's simple. It's mostly correct. It's easy enough for people who aren't experts in both XML and JDOM to use. To use DOM correctly, you really need to be an expert in both XML and DOM.
Bill Venners: In your talk, one complaint you had about JDOM is: "There's more than one way to do it." What's that all about?
Elliotte Rusty Harold: JDOM often provides convenience methods. For
example, suppose you have an
item element in RSS, and you
want to get the content of the
title of that
You can call
getChildElement("title").getText(). You can call
getChildText(). You can call
You can call
getChildTextNormalized(). If you want an attribute,
there are still more methods you can call.
JDOM has lots of convenience methods. The idea is that sometimes you want
the white space removed from either end of this element text you're reading,
sometimes you don't. So they give you methods to do both. Looked at
individually, any one of these methods is fine. My concern is that when you add
them all up, the sheer number of them becomes intimidating. You can't read
the JavaDoc documentation for the
Element class in JDOM,
without saying, "There's just so much here." It's just too big. I would prefer not to
provide so many convenience methods. I would prefer a simpler, smaller API
that can be grokked in one sitting, an API all of whose methods you can see in
maybe one screen.