Provide GSON-based Encoder/Decoder

[asavov]

Affects: 5.3.6 (coming from Spring Boot 2.4.5)

Requirement: Provide GSON-base Encoder/Decoder by analogy with Jackson2JsonEncoder/Jackson2JsonDecoder (in webflux world) and GsonHttpMessageConverter (in mvc world).

Issue found (status closed): spring-projects/spring-boot#9166

Workaround found: https://stackoverflow.com/questions/60854660/set-custom-encoder-decoder-or-typeadapter-for-webclient-using-gson

Let me know if I need to provide more details.

[bclozel]

We've discussed this issue as a team and we can consider this as an improvement, but we're not yet 100% about its timeline.

Unlike Jackson, Gson doesn't support asynchronous parsing so we can't support the entire Decoder contract. Concretely, this means that:

• we can't support Flux<Something> as a method parameter in controllers and handlers, even if the request is application/json
• we can't support media types like nd-json as request input, as they're entirely streaming based

On the other hand, we could still support a partial implementation of the Encoder and Decoder contracts and this is already the case with the Jackson2CborDecoder:

• Controller methods can accept Mono<List<Something>> as arguments - this means the entire request body will be buffered before deserialization. If the request bodies aren't too big, this shouldn't make a big difference at runtime.
• On the writing side, there should be no limitation at all (Flux values and streaming both supported)

Would those limitations work for your use cases?

Note that as pointed out in the StackOverflow answer's comments, the proposed implementation is seriously flawed for the streaming use case, since it assumes that incoming DataBuffer properly split JSON objects - this is not the case and this is likely to cause parsing issues at runtime.

[spring-projects-issues]

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

[spring-projects-issues]

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.

[bclozel]

It's not clear at this point whether a limited encoder/decoder support for GSON would be still helpful to the Spring community. If anyone is interested in this feature, please comment on this issue so we can reconsider this.

[chancekim]

Hello, I think a limited encoder/decoder would be really helpful to many users.
Our company is using spring MVC with GSON and planning to change our application to the Webflux based application.
There is a common request and response classes which are using GSON annotations now, but we have to change those classes to use jackson annotations because Webflux doesn't provide GSON encoder/decoder.
I guess it is happening to many other companies, so I politely request you reconsider of this issue.

[bclozel]

Hi @chancekim - thanks for reaching out!
This is pretty late in the 5.3.x generation and we're working on the upcoming 6.0.x. Introducing a new feature in 5.3.x at this stage would be odd. Would that work for you if this is done for the 6.0.x line? What are your current plans for this MVC->WebFlux change?

[chancekim]

Hi @bclozel !
Yes, even though it will be included in the 6.0.x, it must be helpful, not only me but the others.

[JevgenijZubovskij-UnlikelyAI]

Hi, wanted to double check if it's now possible to use this with 6.0.x WebFlux or is it still an upcoming feature? Asking as the setting spring.mvc.converters.preferred-json-mapper=gson does not seem to propagate to it and it continues using Jackson for deserialising WebClient HTTP payloads

[bclozel]

@JevgenijZubovskij-UnlikelyAI this feature is not implemented and it's in the 6.X Backlog right now. We only got one person interested so far and we never got feedback on the limitations outlined above.

[shanewow]

The Stripe Java API (https://github.com/stripe/stripe-java) is a good use case. All of their models use Gson annotations. Having to re-write their models so they can be used in a WebFlux microservice has been a headache.

[bclozel]

@shanewow would the limitations listed in #27131 (comment) be acceptable for your use case?