| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
|
+1, I'm serialising a large object and it takes about 2000ms on my machine currently. Switching to this implementation drops it down to 50ms. |
Sorry, something went wrong.
|
See jakartaee/jsonp-api#80 it seems there already is a similar PR in Jakarta EE. I doubt that this repository results in any new updates or releases. |
Sorry, something went wrong.
|
@lukasj @bravehorsie Recently there were some similar PRs in different projects. I am not 100% convinced that it's needed. Folks, I want you to review it before letting it go. |
Sorry, something went wrong.
| */ | ||
| public final class Json { | ||
|
|
||
| static final JsonProvider PROVIDER = JsonProvider.provider(); |
There was a problem hiding this comment.
Currently this would actually decrease performance with default implementation if JsonProvider is cached by client application (as it is supposed to). See
Sorry, something went wrong.
There was a problem hiding this comment.
I certainly see dangers making it final. That way for the lifetime of the Json class in a particular JVM it would remain the same even if the underlying provider may change (less likely without OSGi but possible for some implementations)
Keeping a static cache, maybe, as long as there's at least a protected or similar way to reset it, see how we did in JSR 363 with ServiceProvider or CDI.
I am not convinced we still need this in Java EE 8, maybe leave to a future (Jakarta EE) version of JSON-P?
Sorry, something went wrong.
There was a problem hiding this comment.
same comments as in jakartaee/jsonp-api#80 apply here
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
I got through this because I found a performance hostpot in calling Json methods (about 500 microsec per call on a i5)