Chapter 14. JDOM

Tree-based APIs such as DOM are very useful when developers want to keep the entire document in memory at once with random access to the entire tree. Unfortunately, DOM suffers from a number of design flaws and limitations that make it less than ideal as a Java API for processing XML. These include the following:

• DOM needed to be backward compatible with the hackish, poorly thought out, unplanned object models used in third-generation web browsers.

• DOM was designed by a committee trying to reconcile differences among the object models implemented by Netscape, Microsoft, and other vendors . The DOM committee needed a solution that was at least minimally acceptable to everybody, which resulted in an API that's maximally acceptable to no one.

• DOM is a cross-language API defined in IDL. As such, it is limited to the features and classes that are available in essentially all programming languages, including not fully object-oriented scripting languages such as JavaScript and Visual Basic. It is a lowest -common-denominator API that neither takes full advantage of Java nor adheres to Java best practices, naming conventions, and coding standards.

• DOM must work for both HTML (not only XHTML, but also traditional, malformed HTML) and XML.

These four constraints made DOM a lot more clumsy and harder to use than it should have been. I'm virtually certain that if you've read Chapters 9 to 13, you've often found yourself muttering in rather colorful language about some of the more harebrained aspects of DOM. I know I certainly did as I wrote those chapters. In almost every case, the specific problem that elicits such complaints is a result of one of these four design constraints.

JDOM, on the other hand, is a tree-based API for processing XML documents with Java that threw out DOM's limitations and assumptions and started from scratch. It is designed purely for XML, purely for Java, and with no concern for backward compatibility with earlier, similar APIs. It is thus much cleaner and much simpler than DOM. Most developers find JDOM to be far more intuitive and easy to use than DOM. It's not that JDOM will enable you to do anything you can't do with DOM. However, writing the same program with JDOM will normally take you less time and have fewer bugs when finished, simply because of the greater intuitiveness of the API. In many ways, JDOM is to DOM as Java is to C++ a much improved, incompatible replacement for the earlier, more complex technology.

Caution

JDOM is still in beta at the time of this writing. This chapter is based on the most current CVS version available, which is shortly after beta-8 and somewhere before beta-9. The API has been stabilizing, and I don't foresee any major changes between now and 1.0. However, a number of the details are likely to shift. I'd definitely check the method signatures with the latest version of the JavaDoc API documentation.