Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Issues

Select view

Select search mode

 
6 of 6

Filter out synthetic parameters as added by Kotlin (and probably others)

Rejected

Description

Please, look at my post on stackoverflow.com
Validator gets wrong parameter's metadata. Seems that it gets default final fields from Enum type (name, ordinal)

Environment

JDK 8

Attachments

1
  • 04 Jun 2018, 12:48 PM

follows up on

Details

Assignee

Reporter

Labels

Bug Testcase Reminder (view)

Bug reports should generally be accompanied by a test case!

Bug Testcase Reminder (edit)

Bug reports should generally be accompanied by a test case!

Participants

Guillaume Smet
Gunnar Morling
Pavel Pismerov

Components

Affects versions

Priority

Created June 4, 2018 at 7:53 AM
Updated June 13, 2018 at 2:44 PM
Resolved June 12, 2018 at 4:32 PM

Activity

Show:

Pavel PismerovJune 13, 2018 at 2:44 PM

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.

Guillaume SmetJune 12, 2018 at 4:32 PM

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!

Guillaume SmetJune 12, 2018 at 4:24 PM
Edited

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!

Guillaume SmetJune 6, 2018 at 8:01 AM

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

public static Type typeOf(Executable executable, int parameterIndex) { Type[] genericParameterTypes = executable.getGenericParameterTypes(); // getGenericParameterTypes() doesn't return synthetic parameters; in this case fall back to getParameterTypes() if ( parameterIndex >= genericParameterTypes.length ) { genericParameterTypes = executable.getParameterTypes(); } Type type = genericParameterTypes[parameterIndex]; if ( type instanceof TypeVariable ) { type = TypeHelper.getErasedType( type ); } return type; }

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 .

Gunnar MorlingJune 5, 2018 at 8:08 AM

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).

Flag notifications