Affects: 5.3.14, 6.0.0-M2

If you use spring expression to access a public interface method, it instead accesses the method on the implementation class. If that class is not public, the access will fail.

Example: the standard Java collections have Iterator implementations which are private inner classes:

package test;

import java.util.HashMap;

import org.springframework.expression.spel.standard.SpelExpressionParser;

public class SpelTest {

    public static void main(String[] args) {

        var map = new HashMap<String, String>();
        map.put("key", "value");
        var iter = map.entrySet().iterator();
        final Object output = new SpelExpressionParser().parseExpression("hasNext()").getValue(iter);
        System.out.println("output is " + output);

    }

}

Under Java 11 and Spring Framework 5.3.14, the above will succeed with a warning:

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.springframework.util.ReflectionUtils (file:/Users/iay/.m2/repository/org/springframework/spring-core/5.3.14/spring-core-5.3.14.jar) to method java.util.HashMap$HashIterator.hasNext()
WARNING: Please consider reporting this to the maintainers of org.springframework.util.ReflectionUtils
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
output is true

Under Java 17 and either Spring Framework 5.3.14 or 6.0.0-M2, the above will fail:

Exception in thread "main" org.springframework.expression.spel.SpelEvaluationException: EL1029E: A problem occurred when trying to execute method 'hasNext' on object of type 'java.util.HashMap$EntryIterator': 'Problem invoking method: public final boolean java.util.HashMap$HashIterator.hasNext()'

It's worth noting that the equivalent problem for property accesses was described in issue #22242 and fixed in commit dec6d698192df28e6640d8de2c2745f7dd0c146d for 5.1.18 back in 2019. This issue relates to methods instead but it seems like the same approach should be possible.

Comment From: jhoeller

ReflectiveMethodExecutor is trying to get the interface method if possible as well, just like ReflectivePropertyAccessor. I'm not quite sure why this isn't kicking in here, we'll have a look.

Comment From: scantor

From my earlier JDK spelunking, I would speculate that it's because the base class they use for the LinkedHashSet iterators doesn't in fact implement Iterator (or anything else). The subclasses do, but the hasNext method itself is declared on the Abstract base class that doesn't, so it's probably not spotting the interface. It's a bit of an odd layout.

Comment From: jhoeller

Some debugging reveals that it is indeed the interface declaration in a subclass, late-binding a method from the superclass to an interface method, which is not being discovered by our getInterfaceMethodIfPossible algorithm here. I'll revisit this to pass along the original target class, not just operating on the method's declaring class.