Spring Make Kotlin functions accessible in CoroutinesUtils

After updating to spring-webflux 5.2 i noticed that @ExceptionHandler's in private Kotlin-Classes stopped working. After debbuging I found that this regression was introduced with kotlin-coroutines support for reactive Webflux and reactive Messaging handlers.

The Problem is that when converting Java methods to Kotlin functions the information if a method is accessible or not will not be copied and the Kotlin function has to be made accessible again via its isAccessible setter.

For this I introduced a new very simple KotlinReflectionUtils class which both InvocableHandlerMethod's use when Kotlin is available. I'm not 100% sure if this is the best solution and if its worth to introduce a new utils class for this.

Comment From: rstoyanchev

I'm wondering if these classes need to remain private, i.e. is this something we want to work?

Comment From: sdeleuze

I'm wondering if these classes need to remain private, i.e. is this something we want to work?

@rstoyanchev If you mean classe like CoroutinesController in the PR and if that works on Java, I would say yes.

That said, we can't modify org.springframework.core.CoroutinesUtils#invokeSuspendingFunction signature to use KFunction instead of Method, and CoroutinesUtils is now a Java class. So I think I would suggest to modify:

public static Publisher<?> invokeSuspendingFunction(Method method, Object target, Object... args) {
    KFunction<?> function = Objects.requireNonNull(ReflectJvmMapping.getKotlinFunction(method));
    // ...
}

To

public static Publisher<?> invokeSuspendingFunction(Method method, Object target, Object... args) {
    KFunction<?> function = Objects.requireNonNull(ReflectJvmMapping.getKotlinFunction(method));
    if (method.isAccessible() && !kotlin.reflect.jvm.KCallablesJvm.isAccessible(function)) {
        kotlin.reflect.jvm.KCallablesJvm.setAccessible(function, true);
    }
    // ...
}

This will impact other invokeSuspendingFunction invocations as well (not just those from InvocableHandlerMethod), but implemented like that I tend to think that's ok.

@rstoyanchev Do you agree? Is it ok to target 5.3.x for that fix?

Comment From: sdeleuze

We probably need to do the same thing on BeanUtils#instantiateClass and try to detect similar other patterns by a search on ReflectionUtils#makeAccessible usage where kotlin-reflect is involved.

Comment From: rstoyanchev

@sdeleuze I agree, as far as the changes to CoroutinesUtils#invokeSuspendingFunction.

Comment From: sdeleuze

I applied the discussed changes via 8eb618b480896092cae04d1c5e412f7a5dba0c9c on 5.3.x and merged them to main.