Spring Add KClass variant to Coroutines web API

Extend API - add ability to work with Kotlin Coroutines and generic deserialization.

Comment From: pivotal-issuemaster

@imanushin Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

Comment From: pivotal-issuemaster

@imanushin Thank you for signing the Contributor License Agreement!

Comment From: imanushin

@sdeleuze, could you please take a look?

Comment From: sdeleuze

@imanushin Thanks for this PR, could you please give me more detail about your use case? In particular, is it a matter of coding style or are you blocked by the reified type parameter variant? And why does it take a Class and not a KClass parameter ?

Comment From: imanushin

@sdeleuze,

are you blocked by the reified type parameter variant?

Yes. I have generic service, which has KClass on input. It wraps common input logic, when you receive hook-like requests from the different services. In this case I need generic-like deserialization. As workaround, I wrote code bodyToMono(clazz).awaitSingle().

I think, there are people who have the same task. So in additional I extended other methods: for nullable return and for Flow.

And why does it take a Class and not a KClass parameter ?

Just because Class is standard way in Java to pass the instance type. However I can replace it to KClass (moreover, KClass I have in my code on input). What do you think, will KClass be better?

Comment From: sdeleuze

Ok that was I expected. We usually don't provide Class or KClass variant for reified type parameter extensions because the Class based Java variant is enough, but here indeed I can understand how it is annoying to be forced to call the Reactive API then the Reactive to Coroutines conversion API.

I think using KClass here is more idiomatic, so yes please modify this PR to use it instead of Class. Also for the sake of consistency, could you please add similar extensions to ClientResponseExtensions ?

I am also curious if these additional extensions change IntelliJ IDEA autocomplete experience or not, could you please test that with and without the additional extensions? I would like to make sure we do not impact too much 99% of the use cases with this 1% use cases improvement.

Comment From: imanushin

I think using KClass here is more idiomatic, so yes please modify this PR to use it instead of Class.

Yes, of course.

Also for the sake of consistency, could you please add similar extensions to ClientResponseExtensions ?

Yes, will do.

I am also curious if these additional extensions change IntelliJ IDEA autocomplete experience or not, could you please test that with and without the additional extensions? I would like to make sure we do not impact too much 99% of the use cases with this 1% use cases improvement.

Yes... Probably, I didn't catch this fully. Am I right, that you'd like to test, that inline methods will be at the IntelliSence (and at the first places, if possible)? If yes, I'll attach the screenshots

Comment From: sdeleuze

I will check myself the developer experience (last point), please ping me when you have updated the PR with the 2 other points.

Comment From: imanushin

@sdeleuze , done. I also extended API, which returns Kotlin classes.

Comment From: imanushin

@sdeleuze , could you please take look on PR?

Comment From: imanushin

@jhoeller, could you please take a look on the pull request?

Comment From: imanushin

@sdeleuze, @sdeleuze, all changes were applied. I also rebased my commits into the top of master (to avoid merge commit).