He is a entrepreneur and a software architect from Tel Aviv, Israel. He is also a technology freak with about 20 years experience working with computers. He is currently working on his first private initiative in the area of software development tools. His vision is to maximize the abilities of software developers by providing pragmatic tools that enable them to get fast results. Zviki has posted 36 posts at DZone. You can read more from them at their website. View Full User Profile

Efficient XML Processing Using SAX and Java Enums

08.06.2008
| 15418 views |
  • submit to reddit

I had a chance to do some XML crunching lately. I used a design pattern for this purpose which is both efficient and elegant. I'm not sure who thought of this first, so I won't name it after myself (:-), but it's well worth writing about it.

Very Short Introduction to XML Processing in Java


To refresh your memory, here's a short overview of the popular ways for working with XMLs in Java. Briefly, there are two leading methods:

  • SAX - Simple API for XML - event driven method where you write a processor which receives events while the XML is being read. This is also known as "stream parser". Events include Start Document, Start Element, End Element, etc.
  • DOM - Document Object Model - means the XML is modeled a graph of nodes that may be traversed by code with methods like Get Children, Get Parent, etc.

The SAX approach is considered very fast and memory efficient, while the DOM is usually easier to handle by code, especially if the processing requires information from multiple nodes. On top of these two approaches there are many add-on tools that make the developer life a lot easier but usually take their performance toll. Most noticeably, the simplest approach, IMHO, is to take tools like JAXB or XML-Beans, which bind the XML into instances of custom classes which are modeled automatically according to the XML structure definition (DTD or Schema).

 

Choosing SAX


If you're looking for efficient XML processing, SAX is the way to go. It's the hard-core method: you don't get much and you pay accordingly. Writing an XML processor with SAX means implementing an interface called ContentHandler. Here's an example:

class MyContentHandler implements org.xml.sax.ContentHandler {

public void startDocument() throws SAXException {
...
}

public void startElement(String uri, String localName, String name,
Attributes atts) throws SAXException {
...
}

public void endElement(String uri, String localName, String name)
throws SAXException {
...
}
...
}

If your XML has many types of elements to handle, your startElement method is going to be a lengthy method with a very ugly string matching if/else block. For example, parsing XHTML would look a bit like this:

public void startElement(String uri, String localName, String name, 
Attributes atts) throws SAXException {

String lowerCaseName = localName.toLowerCase();

if (lowerCaseName.equals("html")) {
...
} else if (lowerCaseName.equals("head")) {
...
} else if (lowerCaseName.equals("title")) {
...
} ...
}

You wanted hard core and you got it.

Enums to the Rescue


One of my favorite features in Java 5 is enumerations (enums). Since I started using them, I keep finding new uses and new design patterns which are more elegant with enums. If you're not fully familiar with enums, stop reading this article and spend the time trying out the Enums - it will be worth it.

The solution I offer is simple: each element has a corresponding enum constant which holds the code for handling that particular elements. The enum constant name will have the same name as the element name. The correct constant is selected using the Enum static method valueOf. It's a very elegant code which looks like this:

private enum ElementType {
html {
void startElement(Attributes atts) throws SAXException {
...
}
},
head {
void startElement(Attributes atts) throws SAXException {
...
}
},
title {
void startElement(Attributes atts) throws SAXException {
...
}
};

abstract void startElement(Attributes atts) throws SAXException;
}

public void startElement(String uri, String localName, String name,
Attributes atts) throws SAXException {
try {
ElementType.valueOf(ElementType.class, localName.toLowerCase())
.startElement(atts);
} catch (IllegalArgumentException e) {
...
}
}

The above code is based on the built-in valueOf method for choosing the right constant. The solution I presented is also limited by the fact that enum constants must have Java identifier names. Most noticeably, you cannot use a dash in the element name.

The Hash Table Alternative


If you look at the implementation of the valueOf method in java.lang.Enum, you'll see that it is working with a hash table behind the scenes, with enum constant names as keys. In fact, the same solution, less elegant, could be achieved by working with such a map, which holds instances, possibly anonymous classes, that implement an interface for handling the element (much like the enums above).

private interface ElementHandler {
void startElement(Attributes atts) throws SAXException;
}

private static final Map<String, ElementHandler> elements;

static {
elements = new HashMap<String, ElementHandler>();

elements.put("head", new ElementHandler(){
public void startElement(Attributes atts) throws SAXException {
...
}});
...
}

public void startElement(String uri, String localName, String name,
Attributes atts) throws SAXException {
ElementHandler elementHandler = elements.get(localName.toLowerCase());

if (elementHandler != null) {
elementHandler.startElement(atts);
} else {
...
}
}

The above is simpler than using if/else, but it's not as elegant as using enums. As to performance, it depends on the map implementation and the number of element types in the XML. In case you have just a few element type, if/else will be more efficient for sure. Nevertheless, I'm not sure that's worth the awkward code involved. The enum option seems to me the easiest to maintain and expand.

What do you think?

From http://zvikico.typepad.com/problog/

Published at DZone with permission of its author, Zviki Cohen.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Jilles Van Gurp replied on Wed, 2008/08/06 - 7:28am

There's a third form of parsing called xml pull parsing which is similar to SAX in performance but a bit more easy to program. Apache axiom uses this for example and it is also quite common in J2ME.

Finally, unless it is really performance critical, xpath is a nice & robust way to get information out of xml documents. And if you cache the compiled expressions performance is actually pretty good. With DOM the real issue is memory usage and this in turn is only an issue if you are parsing extremely large documents or if you parsing a very large amount of documents. Otherwise, you should be able to run xpath expressions or full xsl transformations in 10-20 ms on normal hardware.

Don't go for the SAX solution unless you have to. The code is more cumbersome to write and maintain and a definite antipattern I've seen a lot is that e.g. order of the tags or attributes is hardcoded in the code because it was easier for the programmer. If you want to enforce that kind of thing, use a schema or DTD.

 

Tom Fennelly replied on Wed, 2008/08/06 - 11:06am

Another option again is to use Smooks.  It supports SAX and DOM processing models and comes with a range of prebuilt "Handlers" for doing a range of things (including java binding, message splitting and more).

Koen VT replied on Thu, 2008/08/07 - 1:48am in response to: Jilles Van Gurp

Yeah, StAX is easy and performant ;-)

Tim Boudreau replied on Thu, 2008/08/07 - 7:32pm

Clever and very readable - I like it - although I pity the poor VM for the number of classes under the hood.

Torbjörn Gannholm replied on Fri, 2008/08/08 - 1:21am

I really like your pattern! Another thing that I've done often when faced with a deeply hierarchical structure is to switch out the content handler. You also get some structure validation from that, e.g. when parsing the contents of a table tag. This is much easier in the C SAX binding because you can switch out each method separately. It's on my TODO list to create a ContentHandler with a stack of ElementHandlers, although I realize as I write this that inheritance could also help avoid re-implementing all ContentHandler methods.

Atin Sood replied on Mon, 2008/08/11 - 1:57am

I think the best way to process data out of XML is Xpath Api.

Tim Boudreau replied on Mon, 2008/08/11 - 5:26pm

I get the feeling all of the people saying "use XPath" or "use this DOM thingy" have never programmed in an environment where you can't, are not allowed to, or just from common-sense, shouldn't touch DOM with a ten foot pole.  DOM-based stuff eats memory like there's no tomorrow and becomes completely unmanageable for very large documents.

 I remember a trying to open the DocBook XML sources of our first book in a DOM-using XML editor with a tree view, back when we were writing it. It took 34 minutes to build the DOM tree for it (500+ page book and a humungous DTD).

The various DOM-based APIs for XML parsers are definitely convenient and useful if you know what you're dealing with is small. But even there, you run the risk that something will hold a reference to a stale tree, which will run you out of memory pretty quick.

I won't be a curmudgeon and say "If you're not writing a browser, you shouldn't be using DOM," (although I think it sometimes), but please appreciate that there are some places, particularly handling arbitrarily long documents which can be very big, where it's really the wrong tool for the job. In those cases you want a visitor-based API like SAX, where you can extract whatever minimal data you need as you go and be guaranteed able to do it in a finite amount of memory.

carlemueller replied on Tue, 2008/08/12 - 5:26pm

I fail to see how XStream doesn't solve your problem in a very small number of lines of code.

Tim Boudreau replied on Fri, 2008/08/15 - 4:52am

A case in point re memory issues and DOM. 30Mb of heap saved in NetBeans 6.5...

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.