The Artima Developer Community
Sponsored Link

Lessons Learned from JDOM
A Conversation with Elliotte Rusty Harold, Part IV
by Bill Venners
July 14, 2003

<<  Page 3 of 3


Don't Release too Early

Bill Venners: You also mentioned in your talk that JDOM taught you not to "release too early."

Elliotte Rusty Harold: For JDOM, I think the first release was beta2, and this was some three years ago now. Brett actually wrote about JDOM in his book Java and XML. By the time his book had come out, JDOM had moved on past that initial release. JDOM has changed a lot in the last three years, even though it still hasn't gotten to 1.0. I think JDOM would have benefited from earlier work with a smaller, more select group. Don't publish to the world quite so soon. Let a few more things gel into place. Then when the select group is fairly happy with it, push it out the door for broader comment. I think a lot of developers got turned off of JDOM relatively early, because they jumped onto the bandwagon too early, and they had to keep revising their code from beta2 to beta3 to beta4 to beta5. They thought JDOM would be more finished than it really was.

Bill Venners: So the trouble with releasing too early is you can alienate some of your audience.

Elliotte Rusty Harold: Yes, you can cause problems for your audience by virtue of not having a finished API.

Bill Venners: I remember seeing a lot of deprecation in JDOM. Is that because JDOM was successful enough that there was sufficient client code out there they didn't want to break, even though JDOM was still beta?

Elliotte Rusty Harold: Yes. Now that deprecated code will all be removed before 1.0, but JDOM does have a policy that when a method is renamed or changed, the old method or class is retained for at least one release as a deprecated method. Unlike Java itself, JDOM will eventually remove all deprecated methods.

Don't Optimize until the API is Right

Bill Venners: You suggested in your talk, "Don't optimize until the API is right."

Elliotte Rusty Harold: I have noticed too many times in the work on JDOM that the arguments against something that is obviously correct are that the performance hit will be too big. But we don't have any decent measurements on exactly where the performance hits are in JDOM. I think correctness should come first. First you get a correct API, and then you go look for opportunities to optimize the code. As Donald Knuth says, "premature optimization is the root of all evil in programming."

Next Week

Come back Monday, July 21 for the final installment of a conversation with Bruce Eckel about why he loves Python. I am now staggering the publication of several interviews at once, to give the reader variety. The next installment of this interview with Elliotte Rusty Harold will appear near future. If you'd like to receive a brief weekly email announcing new articles at, please subscribe to the Artima Newsletter.

Talk Back!

Have an opinion about JDOM? Discuss this article in the News & Ideas Forum topic, A Design Review of JDOM.


Elliotte Rusty Harold is author of Processing XML with Java: A Guide to SAX, DOM, JDOM, JAXP, and TrAX, which is available on at:

XOM, Elliotte Rusty Harold's XML Object Model API:

Cafe au Lait: Elliotte Rusty Harold's site of Java News and Resources:

Cafe con Leche: Elliotte Rusty Harold's site of XML News and Resources:



SAX, the Simple API for XML Processing:

DOM, the W3C's Document Object Model API:



Common API for XML Pull Parsing:


Xerces Native Interface (XNI):

TrAX (Tranformation API for XML):

Jaxen (a Java XPath engine):


<<  Page 3 of 3

Sponsored Links

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