For JSON, the configuration is a slightly different: the only way to specify an alternate im-
plementation is to create one using the META-INF/services route, specifying a file with the
name javax.json.spi.JsonProvider that contains the classname of the new JSON implementa-
tion. There is (unfortunately) no way to circumvent searching the entire classpath when look-
ing for a JSON factory.
The final performance consideration in choosing a parser is the performance of the alternate
implementation. This section can only give a snapshot of the performance of some imple-
mentations; don't necessarily take the results at face value. The point is that there will always
be different parser implementations. In terms of performance, different implementations will
likely leapfrog each other's performance. At some point, alternate parsers will be faster than
the reference implementations (possibly until new releases of the JDK or JSON-P reference
implementation come along and leapfrog the alternate implementation).
At the time of this writing, for example, the alternate Woodstox parser provides a slightly
faster implementation of the StAX parser than what ships with JDK 7 and 8 (see Table 10-5 ).
Table 10-5. Performance of alternate StAX parsers
Items processed JDK StAX parser Woodstox StAX parser
The JSON situation is more muddled. As I write this, the JSON-P specification has just been
made final, and there are no JSR 353-compatible alternate implementations of JSON parsers.
There are other parsers for JSON, and it is only a matter of time until at least some of them
conform to the JSR 353 API.
This is a fluid situation, so it may be a good idea to look for alternate JSON implementations
and see if they offer better performance. One (currently noncompliant) implementation is the
API calls of JSR 353). See Table 10-6 .