Cannot close over local variable #924
Conversation
|
This is also related to #914 - that fix tries to solve a related problem, if not the same. |
| Given("^this data table:$", (DataTable peopleTable) -> { | ||
| List<Person> people = peopleTable.asList(Person.class); | ||
| assertEquals("Hellesøy", people.get(0).last); | ||
| }); | ||
| Integer alreadyHadThisManyCukes = 1; | ||
| Given("^I have 42 cukes in my belly$", () -> { |
There was a problem hiding this comment.
Looks like your change breaks arguments. Try changing this line to the following to reproduce:
Given("^I have (\\d+) cukes in my belly$", (Integer n) -> {Any thoughts about how to deal with that?
There was a problem hiding this comment.
Hmm, I didn't expect it to break that easily. What happens? I can have a look in a couple of days, but not right now unfortunately.
There was a problem hiding this comment.
The lambda parameters are reported as java.lang.Object, so the type conversion breaks.
There was a problem hiding this comment.
Oh well, so much for that technique then ;) If its not caused by the interface methods being declared accepting Object, I have no immediate ideas for workarounds. Maybe merge the other fix and I'll see if there is a way around it at nearest occation. Should have tested it better :)
There was a problem hiding this comment.
It's funny though - the documentation for getGenericParameterTypes says "If a formal parameter type is a parameterized type, the Type object returned for it must accurately reflect the actual type parameters used in the source code.".
|
I found that https://github.com/jhalterman/typetools/blob/master/src/main/java/net/jodah/typetools/TypeResolver.java also uses the constant pool to resolve lambda arguments, so maybe your old method is the only viable. http://stackoverflow.com/questions/21887358/reflection-type-inference-on-java-8-lambdas certainly seems to implicate that. Perhaps using typetools is a good idea, so that support for new JDKs can be added there? In either case, dcowboys fix seems to be the right one (it's the same method as used by TypeResolver). |
|
See #929 for a new attempt |
|
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
This is a reproducing test and suggested fix for issue #916. The problem turned out to be that the information read out of the ConstantPool didn't actually represent the type signature of the lambda class when we had closed over local variables.
I also saw issue #912 which is related to that the constant pool interface isn't uniform or stable, so I decided to try to avoid it altogether.
So instead of trying to deduce the type signature of the body class, I look at the concrete types of the "accept" method parameters. I'm not sure if this is equivalent to the old method and if there are some cases which it doesn't cover, but at least all tests are passing in the project.
This fix also leads to the TypeIntrospector being unused, but I didn't remove it in the pull request to avoid cluttering.