Thank you for your researching. I already did it. But my Spring issue was closed with comment to continue discussion on SO.

I will try to do it again and I will let you know about results.

Hum, in fact, digging a bit more, it's not an issue with Kotlin, it's an issue with what Spring is trying to do.

In KotlinReflectionParameterNameDiscoverer, they should at least check that the Kotlin function/constructor returns the same number of parameters than the Java method/constructor before considering they are interchangeable.

It is definitely not the case with Kotlin enums as Kotlin has added synthetic parameters in the JVM constructors.

Kotlin does not return the synthetic parameters added to the JVM version so either Spring has to fill the gaps with forged names or they have to return the parameter names coming from the JVM if the elements does not match.

Could you open a Spring issue then?

Thanks!

I thought about it more today and I don't think we can do something in HV.

The ParameterNameProvider API is dealing with methods and constructors directly and we can't really change it to ignore synthetic parameters. I could do the change in HV but that would break the Spring use case as they are using their own ParameterNameProvider which does not ignore synthetic parameters in the standard Java reflection case.

Thus, I think it's an issue with Kotlin: Kotlin should report consistently either all the parameters or only the non synthetic parameters but shouldn't report one or the other depending on the method calls.

As mentioned in the SO answer:

• the constructor as provided by the reflection API is: com.test.simple.Group(java.lang.String $enum$name, int $enum$ordinal, java.lang.String groupName, java.lang.String groupDescription) so it has four parameters. I suppose the name and the ordinal are passed to the constructor;

• the parameter names as provided by KotlinReflectionParameterNameDiscoverer are only [groupName, groupDescription] (so not taking into account the additional parameters).

Could you open a Kotlin issue and see what they are thinking about it?

I would appreciate a follow-up here with a link to the issue.

Thanks!

When I worked on it the other day, the only thing I could find about synthetic parameters was:

We do not exclude them as far as I can tell.

Interesting discussion here: https://bugs.openjdk.java.net/browse/JDK-8062582?focusedCommentId=13570978&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13570978 .

I think we already exclude synthetic parameters in some places (or at least deal with the fact that they are exposed in some places but not others; IIUC, there's a TODO with a reference to some JDK bug somewhere in the code).