SpEL chooses wrong method to invoke when varargs method is present [SPR-12803]

[spring-projects-issues]

Lior Lipshitz opened SPR-12803 and commented

I'm trying to evaluate the following SpEL expression:

T(com.google.common.collect.Lists).newArrayList(#iterable)
where #iterable is of type java.lang.Iterable. Google Guava com.google.common.collect.Lists (version 14.0) does have a method newArrayList(Iterable) but for some reason SpEL chooses to invoke a different method: newArrayList(Object[])

The issue seems to be with org.springframework.expression.spel.support.ReflectiveMethodResolver implementation: it seems to be sensitive to the manner in which methods are sorted by the java.lang.Class::getMethods. If 2 methods match the invocation (in the case one of the methods is varargs), the later method (in the order) will be invoked, instead of choosing the method that isn't varargs (which is more specific). It seems like JDK doesn't guarantee the order the methods are sorted: different runs yield different order.

---

Affects: 3.1.1

Reference URL: http://stackoverflow.com/questions/28924430/spring-spel-chooses-wrong-method-to-invoke

Issue Links:

• SpEL: problem with static methods conflicting with instance methods [SPR-12502] #17107 SpEL: problem with static methods conflicting with instance methods
• VerifyError when trying to compile constructor invocation with SpEL [SPR-12326] #16931 VerifyError when trying to compile constructor invocation with SpEL
• SpEL's ReflectiveMethodResolver should use distance computation by default [SPR-12808] #17405 SpEL's ReflectiveMethodResolver should use distance computation by default

[spring-projects-issues]

Juergen Hoeller commented

I'm going to have a look at this against the latest 4.2 version of the code, making sure that we reliably choose direct matches over varargs matches. Depending on the impact on the code, this is likely to be backported to 4.1.6 in about two weeks.

In general, please make sure to report such issues against recent versions of Spring. Support for the 3.1.x line ended years ago; even 3.2.x is about to be end-of-lifed rather soon. That said, if this issue turns out to be easy enough to backport, we can consider making it available in the 3.2.14 release in May as well.

[spring-projects-issues]

Juergen Hoeller commented

Note that this has been fixed as of Spring Framework 4.1.2 already, through #16931 - a larger SpEL revision which explicitly fixed this case as well (see Andy's comments there).

I'm considering an isolated backport for this specific issue to 3.2.14. Unstable reflection results for such obvious cases are quite unpleasant, after all. And we haven't had any regression reports against 4.1.2's changes in that space, so a backport to 3.2.x should be rather safe.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

Resolved for 3.2.14 now, along the lines of #16931's changes in the 4.1.x line. Also including some preparations for #17405.

Juergen