Take Weiland opened SPR-16598 and commented

Support specifying defaults for e.g. @RequestMapping via Kotlin parameter default values like so:

@GetMapping
fun get(@RequestParam limit: Int = 20)

Such a method should behave equivalent to @RequestMapping with defaultValue, except that the value does not need to be processed by converters, etc.

This can be implemented in org.springframework.web.method.support.InvocableHandlerMethod using Kotlin Reflection (KCallable#callBy), which allows omitting parameters with default values.

Affects: 5.0.4

Referenced from: pull request https://github.com/spring-projects/spring-framework/pull/1741

2 votes, 5 watchers

Comment From: spring-projects-issues

Alex Rader commented

In Kotlin @RequestBody required=false when use default arguments https://github.com/spring-projects/spring-boot/issues/12691

Comment From: spring-projects-issues

Sébastien Deleuze commented

As discussed in the PR, current Kotlin API force us to integrate that as a rather involved and not very elegant way, I will raise and discuss that point with Kotlin team. As a consequence, I think it is more reasonable to target 5.2 for that one.

Comment From: AlexTrotsenko

Is there any updates on this issue?

Comment From: cmdjulian

I'm also interested in this feature.

Comment From: jlous

The pull-request was closed in August 2020.

Comment From: jlous

Resolving the value in Spring (like a defaultValue) is not feasible, because Kotlin's default is not a simple value but a piece of essentially arbitrary object-internal kotlin code, which Spring has no access to.

An alternative approach would be to use @JvmOverloads to have kotlin generate explicit permutations of the method signature. Spring would need to select the right one depending on which params are present, in stead of rejecting them all as ambiguous endpoint mappings like it does now. One would still need to define a sane course of action if that annotation is missing. Bad request?

In any case: the situation today is that a kotlin endpoint with a default value will run without incident right up until a request without the parameter arrives, in which case it will just throw an NPE from way inside Spring's parameter mapping. That has got to be the wrong approach whichever way you look at it.

Comment From: igorwojda

@jlous I would like to understand this issue a bit more. What exactly is required on the Kotlin side to make this work as expected with Spring (no duplicated default values)? Perhaps the ability to access default value via reflection?

Comment From: igorwojda

I have opened an issue in Kotlin issue tracker: https://youtrack.jetbrains.com/issue/KT-56893/Provide-a-way-to-read-default-argument-values

Comment From: sdeleuze

Let's try to see if we can support that in 6.1 (no promise but I will try).

Comment From: sdeleuze

As discussed in the Kotlin issue, we are probably going to handle this with a refined variant of the original PR.

Comment From: sdeleuze

I have pushed support for Kotlin parameter default values in handler methods. It allows to write: @RequestParam value: String = "default" as an alternative to: @RequestParam(defaultValue = "default") value: String

Both Spring MVC and WebFlux are supported, including on suspending functions.

The changes are quite involved, so I would appreciate feedback based on Spring Framework 6.1.0-SNAPSHOT.

Comment From: Quantum64

This change caused a regression in our project related to calling suspend functions with @JvmInline value class arguments in @Lazy constructor injected beans.

java.lang.IllegalArgumentException: object is not an instance of declaring class
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.base/java.lang.reflect.Method.invoke(Method.java:568)
    at kotlin.reflect.jvm.internal.calls.ValueClassAwareCaller.call(ValueClassAwareCaller.kt:190)
    at kotlin.reflect.jvm.internal.KCallableImpl.callDefaultMethod$kotlin_reflection(KCallableImpl.kt:207)
    at kotlin.reflect.full.KCallables.callSuspendBy(KCallables.kt:74)
    at org.springframework.core.CoroutinesUtils.lambda$invokeSuspendingFunction$2(CoroutinesUtils.java:124)
    at kotlin.coroutines.intrinsics.IntrinsicsKt__IntrinsicsJvmKt$createCoroutineUnintercepted$$inlined$createCoroutineFromSuspendFunction$IntrinsicsKt__IntrinsicsJvmKt$4.invokeSuspend(IntrinsicsJvm.kt:270)
    at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
    at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:108)
    at kotlinx.coroutines.EventLoop.processUnconfinedEvent(EventLoop.common.kt:68)
    at kotlinx.coroutines.internal.DispatchedContinuationKt.resumeCancellableWith(DispatchedContinuation.kt:375)
    at kotlinx.coroutines.intrinsics.CancellableKt.startCoroutineCancellable(Cancellable.kt:30)
    at kotlinx.coroutines.intrinsics.CancellableKt.startCoroutineCancellable$default(Cancellable.kt:25)
    at kotlinx.coroutines.BuildersKt__Builders_commonKt.withContext(Builders.common.kt:172)
    at kotlinx.coroutines.BuildersKt.withContext(Unknown Source)

Comment From: sdeleuze

@Quantum64 Please create a dedicated issue with a reproducer.

Comment From: efemoney

@sdeleuze This change caused another regression using extension receivers. Not necessarily a regression, more a bug as the change just completely ignores Kind.EXTENSION_RECEIVER.

I think java's lack of exhaustive checks for non-expression switch statements is to blame here.

Comment From: sdeleuze

@efemoney Could you please create a new issue with a reproducer please (attached archive or link to a repository)?

Comment From: efemoney

Sure, let me do that.

Comment From: efemoney

@sdeleuze I see you just fixed this yesterday. Looking forwrd to the release. Sorry I didnt get to creating an issue.