He didn't like the use of integer type codes, preferring to have objects. I view StAX as a replacement for SAX, which is basically the bottom of the stack for XML processing API's. You can use SAX or StAX to build trees or beans or whatever you like. So any performance penalty that you impose on StAX is something you've imposed on everybody above you in the food chain, and there's no way to get that performance back if you need it. I think that they did the right thing here. The performance of reflection is never going to match integer comparison. Also, Andy Clark, the author of NekoPull is a member of the expert group as well.

As noted, the state management is much easier than SAX -- it allows you to write a more recursive-descent style of object construction. One of the problems with SAX is that it's very hard to use it to create objects in a way that allows you to reuse the objects and the SAX handler for building those objects. StAX makes that go away.

In many cases what you want is an easy to manipulate representation of the XML data. This is very frequently a Java Bean. So what you really want is an API that takes an XML stream, and gives me back the right Java Bean. And that's what XMLBeans is all about.

So in my view of the Java XML API world, there's StAX at the bottom, and on top of that you have XMLBeans. If you need to do weird document editing tree stuff, then there's StAX at the bottom, and on top of that there's the DOM or XOM or JDOM or whatever. But for most applications that I've worked on, the combination of StAX and XMLBeans would cover it. If you look at the XMLBeans Roadmap, you'll see that one of the goals is to support StAX (JSR 173), which would mean one stop shopping, er, downloading. My hope is that as XMLBeans evolves we'll be able to have a simple to use library.