The Jackson dependency can be a burden for some apps (Gson is faster, and some people just prefer it). It would be good to provide an option. It's complicated in webflux by the fact that Gson doesn't support non-blocking rendering out of the box, but probably worth it.
Comment From: wilkinsona
It's complicated in webflux by the fact that Gson doesn't support non-blocking rendering out of the box
That's a bit more than a complication, isn't it? Doesn't it mean that it's currently impossible in WebFlux?
Comment From: dsyer
I don't know if it's impossible. A lot of the time we have all the data that need to be rendered, so it wouldn't block to render it in memory. Even when the data are not to hand, they are never truly streaming (we don't support SSE in actuator endpoints for instance), so you could always wait till they are available and render in one go. It's the same as what Webflux already has to do to support a non-streaming template engine (i.e. anything other than some special cases in Thymeleaf), isn't it?
Comment From: wilkinsona
This feels more important now in light of #18139. Moving up to 2.x.
Comment From: philwebb
I wonder if we should try to fail hard if GSON is used? We're getting a few bug reports because it appears to work even though we don't support it.
Comment From: dsyer
Also maybe this is interesting: https://github.com/FasterXML/jackson-jr
Comment From: bclozel
We've just fixed #12951, so as of Spring Boot 2.3, an application can choose Gson as a preferred JSON mapper and not risk Actuator endpoint responses being broken.
12951 also makes the JSON mapper actuator-specific and independent of application configuration. Right now Actuator has a hard dependency on Jackson, but this change means that this is now an internal implementation detail. In the future, we might want to revisit this issue, replacing the internal ObjectMapper instance with Gson or Jackson jr.
Note that there are several reasons why we stick to Jackson now:
- it's very likely to be used by the application anyway
- the serialization of configuration properties requires some advanced JSON mapper customization (because we deal with proxies, cycles, etc)
- "simple" serializers aren't enough in many cases, where we don't want to serialize all object attributes
Comment From: philwebb
We're cleaning out the issue tracker and closing issues that we've not seen much demand to fix. Feel free to comment with additional justifications if you feel that this one should not have been closed.
Comment From: pedrohms
still not working with Gson. Has anyone found an alternative?