Closed antechrestos closed 5 months ago
@antechrestos Can you please provide a reproducer as an attached project or a link to a repository?
I confirm this change of behavior caused by the fact that generation of lambda functions using invokedynamic is now the default, and I don't think we can do something about it at Spring Framework level except in terms of documentation so I turn it into a documentation issue.
FYI SAM-converted lambda like HelloHandler { ... }
were already generated via invokedynamic as of Kotlin 1.5, for non regular lambda { ... }
that new in Kotlin 2.0, and @JvmSerializableLambda
can be used as a workaround (fun helloConsumer(helloHandler: HelloHandler): (Flux<Message<ByteArray>>) -> Mono<Void> = @JvmSerializableLambda { ...)
.
@antechrestos Could you please create a related issue in Spring Cloud Function linking the repro in order to allow @olegz and @sobychacko to review how BeanFactoryAwareFunctionRegistry
(sources) logic could be changed?
I confirm that the workaround using@JvmSerializableLambda
makes the trick.
@sdeleuze do you want me to close this PR and let the PR on cloud-function repository be the reference?
@antechrestos if I am not mistaken, this is an issue not a PR and I have repurposed it to refine the documentation, so please keep it opened, I will close it with a related commit.
Using the spring cloud stream with reactive used to work well by instanciating kotlin function as follows
Moving to kotlin 2.0 fails as generated bean class returns
false
when passing it toKotlinDetector.isKotlinType
. Hence starting of spring cloud stream module fails asKotlinFunctionWrapper
is not put and theConfiguration
expects javaFunction
,Consumer
orSupplier
...