There is more to JDOM than what you’ve seen in the brief tour in this chapter. The next chapter will cover the capabilities of the various JDOM classes like Element and Attribute in depth, as well as taking a deeper look at how these constructs are represented. However, before we take that up, it’s worth taking a few minutes to note the features JDOM doesn’t have, and that might lead you to choose a different API instead.

First of all, JDOM cannot handle documents larger than available memory. JDOM loads the entire document tree into memory and keeps it there. JDOM is more memory efficient than some DOM implementations and less efficient than others. However, it’s never going to be competitive with SAX or XMLPULL for truly humongous documents.

Secondly, like both DOM and SAX, JDOM presents a logical model of XML documents. It does not track every last byte of the documents it parses. For instance, it cannot tell which physical entities any element came from. It treats the document as a logical whole. It cannot tell whether a character was input literally or with a character reference (a limitation it shares with DOM and SAX). It does not know the original character encoding of the document. In short, it cannot guarantee byte-for-byte faithful round trips. Merely parsing a document with JDOM and then immediately writing it back out again, may create a subtly different document, though it should still contain the same basic information.

Third, JDOM is purely about the instance document. It does not provide any real model of the DTD or schema. It cannot tell you what the type of an element is, or what its valid children are. It cannot check a Document object against a schema or a DTD.

Finally, JDOM does not currently provide any equivalent to the traversal package in DOM. This isn’t a huge problem, since writing your own tree-walking code does not require a great deal of effort, as you’ll see in the next chapter. However, a standard way of doing this would be helpful.