Java and XML, Second Edition

Gotcha!

As in previous chapters, I want to revisit some of the common pitfalls for new XML Java developers. In this chapter, I have focused on the Document Object Model, and this section continues that emphasis. Although some of the points made here are more informational than directly affective on your programming, they can be helpful in making design decisions about when to use DOM, and instrumental in understanding what is going on under the hood of your XML applications.

Memory, Performance, and Deferred DOMs

Earlier, I described the reasons to use DOM or SAX. Although I emphasized that using the DOM requires that the entire XML document be read into memory and stored in a tree structure, enough cannot be said on the subject. All too common is the scenario where a developer loads up his extensive collection of complex XML documents into an XSLT processor and begins a series of offline transformations, leaving the process to grab a bite to eat. Upon returning, he finds that his Windows machine is showing the dreaded “blue screen of death” and his Linux box is screaming about memory problems. For this developer and the hundreds like him, beware the DOM for excessively large data!

Using the DOM requires an amount of memory proportional to the size and complexity of an XML document. However, you should dig a bit further into your parser’s documentation. Often, today’s parsers contain a feature modeled on what it typically called a deferred DOM . A deferred DOM tries to lower the ...