spring-projects
Provide GSON-based Encoder/Decoder
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): https://github.com/spring-projects/spring-boot/issues/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.
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 isapplication/json - we can't support media types like
nd-jsonas 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 (
Fluxvalues 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.
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.
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.
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.
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.
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?
Hi @bclozel ! Yes, even though it will be included in the 6.0.x, it must be helpful, not only me but the others.
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
@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.
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.
@shanewow would the limitations listed in https://github.com/spring-projects/spring-framework/issues/27131#issuecomment-874160517 be acceptable for your use case?
@bclozel the usage of the GSON lib, in general, remains quite high based on my experience. If someone is already using GSON for serialization, then the lack of support for streamed types shouldn't come as a surprise. I can prepare a PR for this, provided it aligns with the framework’s development vision.
@encircled thanks for the offer but I think I already have the change ready. I never pushed it because I never got any answer from interested parties about the limitation I highlighted in my previous comments.
I'm not denying GSON's popularity, I'm merely wondering if this will get any usage in the community given the limitation involved.
Just wanted to voice my support for this, given the unfortunate lack of interest so far. Streaming isn't necessary for most JSON parsing in my opinion, so even with the limitations that've been discussed it would be a more than welcome addition, especially when it comes to interop with libraries that have data classes setup for GSON already, would remove a lot of tedious code.
