The Artima Developer Community
Interviews | Discuss | Print | Email | First Page | Previous | Next
Sponsored Link

A Design Review of JDOM
A Conversation with Elliotte Rusty Harold, Part III
by Bill Venners
June 30, 2003

Page 1 of 3  >>


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.

A Short History of JDOM

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.

JDOM Offers Many Convenience Methods

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 item. You can call getChildElement("title").getText(). You can call getChildText(). You can call getChildTextTrim(). 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.

Page 1 of 3  >>

Interviews | Discuss | Print | Email | First Page | Previous | Next

Sponsored Links

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use