DefaultParameterNameDiscoverer currently registers KotlinReflectionParameterNameDiscoverer (if Kotlin reflection support is present on the classpath) first, before StandardReflectionParameterNameDiscoverer.
However, since Spring Framework primarily targets Java based applications and libraries, we should register StandardReflectionParameterNameDiscoverer before KotlinReflectionParameterNameDiscoverer in order to optimize for common use cases (even if the optimization is only minimal).
Comment From: sdeleuze
I was suspecting potential regressions involved by this proposal, so I worked on #30618 which confirmed flipping the order between KotlinReflectionParameterNameDiscoverer and StandardReflectionParameterNameDiscoverer introduces regression when Java reflection provide different names than Kotlin one, for example with extension functions.
As a consequence, and since the optimization involved by this proposal is minimal, I decline it.
Comment From: sbrannen
Understood. Thanks for investigating the topic and providing the rationale. 👍