Cache JsonProvider.provider() result as per javadoc recommendation

[gbloisi]

I got through this because I found a performance hostpot in calling Json methods (about 500 microsec per call on a i5)

[lukasj]

given the API may be part of some application server, thus loaded through the main classloader - what happens if some app decides to use its own jsonp implementation and there is some server default implementation already cached by the api? Which implementation will the custom app see?

[gbloisi]

Is there a common pattern to cache singleton instances with classloader specific implementations? I may lookup at some examples and adapt for this case. Thanks

[lukasj]

you may want to look at Issue #26 . The javadoc is targeted to users of the API, not to the API itself

[cwhite102]

Is this fix going anywhere soon?
I believe this bug is why calls to Json.createValue() are a huge performance issue. (each create value call is >100us)

[JohnTimm]

you may want to look at Issue #26 . The javadoc is targeted to users of the API, not to the API itself

@lukasj
This is not a sufficient solution when the internal implementation calls Json.createXXX methods that in turn calls JsonProvider.provider(). What about a solution that a) allows clients to set the provider used by the javax.json.Json class and b) does it on a per context class loader basis to support container environments with multiple class loaders? I put together a "straw man" here:

#205 (comment)