Evaluate alternatives for JSON CODEC


Looks like the bootstrap and runtime performance of GSON is quite disappointing.

We might need to evaluate alternative libraries, or possibly reason about using the stream API of GSON. Theoretically we could "hand roll" some of the crucial parts, as some of the requests we generate are well known.

Current candidates:

EDIT: also to be taken into account, it'd be great if the parser was non-blocking. See




Yoann Rodière
July 12, 2017, 6:56 AM

This, and especially JSON streaming, is definitely 6.x material. There is a number of design facts that, right now, require random access to the JSON structures.

Careful if choosing something else than GSON though: we're using some features of GSON (like TypeAdapters) which may not be present in performance-focused libraries.

On the other hand, I think one improvement we could roll quite easily is avoid JSON parsing altogether in some cases. For instance, right now when we create a document and receive a HTTP status 200 response, we parse the response, but we don't do anything about it. We probably could avoid this parsing. Not sure the performance impact would be high though, since we try to bulk such requests, and when receiving a bulk response we definitely need to parse the response.
I'll create a ticket to investigate that:

Sanne Grinovero
July 28, 2017, 8:31 AM

Yes this is likely material for 6+, but also after my work on optimising the GSON to Http client encoding it doesn't look that bad anymore: my main concern is no longer a problem according to flight recorder.

Might still be interesting to evaluate alternatives, especially Jackson as it's used by other projects on WildFly already so it would reduce the overall set of dependencies and the associated costs of having loads of dependencies in the same platform.




Sanne Grinovero


Suitable for new contributors


Pull Request


Feedback Requested



Fix versions