Support taking @Param name from debug info [DATAJPA-46] about spring-data-jpa

[spring-projects-issues]

Oliver Drotbohm commented

Actually Parameters already does parameter name discovery using a LocalVariableTableParameterNameDiscoverer so that should work as is right now. It just seems to be a matter of documentation though ;)

[spring-projects-issues]

Stevo Slavić commented

Yes, it's there, but doesn't work for me - parameterNamesCache is always empty map. It seems debug information is not available for interfaces

[spring-projects-issues]

Stevo Slavić commented

As stated in VM spec here and here

??The LocalVariableTable attribute is an optional variable-length attribute of a Code (§4.7.3) attribute.??

??The Code attribute is a variable-length attribute used in the attributes table of method_info structures. A Code attribute contains the Java virtual machine instructions and auxiliary information for a single method, instance initialization method (§3.9), or class or interface initialization method (§3.9). Every Java virtual machine implementation must recognize Code attributes. If the method is either native or abstract, its method_info structure must not have a Code attribute.??

Since all interface methods are implicitly abstract, JVM ??must not have?? LocalVariableTable for interface methods.

So, this can not be implemented. Maybe in Java 8+ or maybe using something like ParaNamer but that would introduce additional dependency and I'm not sure if it would work..

[spring-projects-issues]

Stevo Slavić commented

Combining custom annotation processor (based on this it seems annotation processor can access parameter names for interface method) and custom implementation of ParameterNameDiscoverer could do the trick

[spring-projects-issues]

Stevo Slavić commented

Problem is that Parameters can not be configured to use custom ParameterNameDiscoverer different from LocalVariableTableParameterNameDiscoverer. Also there seems to be no support for just extending Spring Data JPA with custom query lookup strategy. Option that remains is to implement custom repository factory

[spring-projects-issues]

Oliver Drotbohm commented

I've just pushed a fix for DATACMNS-356, which lets our Parameters value object use Spring 4's DefaultParameterNameDiscoverer if present. That one uses the new JDK 8 reflection API so that parameter names are resolvable for interface methods if you run the code with -parameters option.

I'll keep this ticket around here to set up a CI build job to run against a recent JDK 8 (b100 required) and see what the consequences are. It's likely that some of the integration tests fail as they expect to work with positional parameter binding and might be trapped into by-name binding as we find parameter names all of a sudden

[spring-projects-issues]

Oliver Drotbohm commented

This is effectively in place with the constraints mentioned in a former comment. When running on Spring 4 and Java 8 with the -parameters flag enabled for compile (should be activated by default), this should work out of the box. Marking as resolved against 1.5 as this was the version Spring Data Commons (1.6) started to integrate with Spring 4 parameter name discovery