Skip to content

ResolvableType should support resolving lambda types [SPR-13698] #18273

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.

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

Closed
spring-projects-issues opened this issue Nov 17, 2015 · 6 comments
Closed
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: bulk-closed An outdated, unresolved issue that's closed in bulk as part of a cleaning process

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Nov 17, 2015

Oliver Drotbohm opened SPR-13698 and commented

This test case currently fails:

Function<Long, String> toString = value -> value.toString();

ResolvableType type = ResolvableType.forClass(Function.class, toString.getClass());

assertThat(type.getGeneric(0).getRawClass(), is(typeCompatibleWith(Long.class)));
assertThat(type.getGeneric(1).getRawClass(), is(typeCompatibleWith(String.class)));

This helper library (itself inspired by Spring's GenericTypeResolver) seems to use an additional code path to use API introduced in Java 8 to resolve lambdas in a special way.


Issue Links:

@spring-projects-issues
Copy link
Collaborator Author

Stéphane Nicoll commented

I thought we had already such report (with a lengthy discussion with thomas.darimont) but I can't find it anymore

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

Indeed, we rejected in back then since the "API introduced in Java 8" is actually internal (sun.reflect.ConstantPool), and the entire approach is rather hacky, even relying on the index of entries in the constant pool... This is very likely to break on JDK 9 eventually, so I'm reluctant to add support for it at this point.

Juergen

@spring-projects-issues
Copy link
Collaborator Author

Oliver Drotbohm commented

Maybe we should bring this up with the JDK team then, they might be able to fix this? I haven't looked deeply into the code but is there a particular reason the standard lookup algorithm doesn't work here? I just think it's kind of weird to see a lambda failing while the very same declaration works if you create the anonymous class. It basically subverts our "use Java 8 and everything will be better" message to some degree.

@spring-projects-issues
Copy link
Collaborator Author

Oliver Drotbohm commented

I just ran into this again with code that was expecting a Converter and I thought I could just hand in a lambda, which I couldn't as the called code was inspecting the given instance for generic types. I think that's the main issue with this one: for a user it's not at all obvious whether you can use a lambda with a SAM type or not.

@spring-projects-issues
Copy link
Collaborator Author

Oliver Drotbohm commented

For reference, here's the discussion I had with the JDK team: http://mail.openjdk.java.net/pipermail/compiler-dev/2016-December/010623.html

@spring-projects-issues spring-projects-issues added status: waiting-for-triage An issue we've not yet triaged or decided on type: enhancement A general enhancement in: core Issues in core modules (aop, beans, core, context, expression) labels Jan 11, 2019
@spring-projects-issues spring-projects-issues removed the type: enhancement A general enhancement label Jan 11, 2019
@rstoyanchev rstoyanchev added status: bulk-closed An outdated, unresolved issue that's closed in bulk as part of a cleaning process and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Jan 11, 2019
@spring-projects-issues
Copy link
Collaborator Author

Bulk closing outdated, unresolved issues. Please, reopen if still relevant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: bulk-closed An outdated, unresolved issue that's closed in bulk as part of a cleaning process
Projects
None yet
Development

No branches or pull requests

2 participants