Skip to content

Register Kotlin support after Java support in DefaultParameterNameDiscoverer #30052

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
sbrannen opened this issue Feb 28, 2023 · 2 comments
Closed

Register Kotlin support after Java support in DefaultParameterNameDiscoverer #30052

sbrannen opened this issue Feb 28, 2023 · 2 comments
Assignees
@sdeleuze
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: declined A suggestion or change that we don't feel we should currently apply theme: kotlin An issue related to Kotlin support type: enhancement A general enhancement

Comments

@sbrannen
Copy link
Member

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).
@sbrannen sbrannen added in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement labels Feb 28, 2023
@sbrannen sbrannen added this to the 6.1.0-M1 milestone Feb 28, 2023
@sdeleuze sdeleuze added the theme: kotlin An issue related to Kotlin support label Jun 8, 2023
@sdeleuze sdeleuze mentioned this issue Jun 8, 2023
Closed
sdeleuze added a commit to sdeleuze/spring-framework that referenced this issue Jun 8, 2023
@sdeleuze
Refine Kotlin ParameterNameDiscoverer tests
2f78b42 
Related to spring-projectsgh-30052, we should improve ParameterNameDiscoverer
Kotlin tests to make sure DefaultParameterNameDiscoverer behaves
as expected and is consistent with
KotlinReflectionParameterNameDiscoverer behavior.

Closes spring-projectsgh-30618
@sdeleuze
Copy link
Contributor

sdeleuze commented Jun 8, 2023

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.

@sdeleuze sdeleuze closed this as not planned Won't fix, can't repro, duplicate, stale Jun 8, 2023
@sdeleuze sdeleuze removed this from the 6.1.0-M1 milestone Jun 8, 2023
@sdeleuze sdeleuze added the status: declined A suggestion or change that we don't feel we should currently apply label Jun 8, 2023
@sbrannen
Copy link
Member Author

sbrannen commented Jun 8, 2023

Understood. Thanks for investigating the topic and providing the rationale. 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@sdeleuze sdeleuze

Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: declined A suggestion or change that we don't feel we should currently apply theme: kotlin An issue related to Kotlin support type: enhancement A general enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@sbrannen @sdeleuze