The only difference in the program logic here is that an exception must be thrown to signal
that parsing is completed, since that's the only way the XML push parsing framework can
detect that parsing should stop. The application-defined SAXDoneException is the class this
example defines for that case. In general any kind of SAXException can be thrown; this ex-
ample uses a subclass so that the rest of the program logic can differentiate between an actual
error and the signal that processing should stop.
SAX parsers tend to be faster than StAX parsers, though the performance difference is
slight—the choice of which parser to use should be made based on which model is easiest to
use in development. Table 10-4 shows the difference in processing time between the push
and pull parsers.
Table 10-4. Performance of push parsers
Items processed XML StAX parser XML SAX parser
There is no corresponding push parser model for JSON-P.
Alternate parsing implementations and parser factories
The XML and JSON specifications define a standard interface for parsers. The JDK provides
a reference implementation of the XML parser, and the JSON-P project provides a reference
implementation of the JSON parser. Applications can use any arbitrary parser (as long as it
implements the desired interfaces, of course).
Parsers are obtained via a parser factory. Using a different parser implementation is a matter
of configuring the parser factory to return an instance of the desired parser (rather than the
default parser). There are a few performance implications around this:
▪ Factory instantiation is expensive: make sure the factory is reused via a global (or at least
a thread-local) reference.
▪ The configuration of the factory can be achieved in different ways, some of which (in-
cluding the default mechanism) can be quite suboptimal from a performance standpoint.
▪ Different parser implementations may be faster than the default ones.