Non-deterministic behavior calling overloaded methods

[glassfishrobot]

The code in ELUtil#findMethod() is broken, it depends on the order of elements of Class#getMethods():

for (Method m: klass.getMethods()) {
            if (m.getName().equals(method) && (
         m.isVarArgs() ||
         m.getParameterTypes().length==paramCount)){
return m;
            }
        }

The first method returned by Class#getMethods() with a matching name and parameter count will be used, someone ignored that "The elements in the array returned are not sorted and are not in any particular order."

This leads to seemingly random exceptions if you have overloaded methods:

public class Main {

    public static class Foo {
        // If you change the order of these two method declarations, bad things happen (sometimes) 
        public Foo bar(String b) {
            return this;
        }

        public Foo bar(int i) {
            return this;
        }
    }

    public static void main(String[] args) throws Exception {
        ELProcessor elp = new ELProcessor();
        elp.defineBean("foo", new Foo());
        elp.eval("foo.bar('abc')");
    }
}

Sometimes the bar(String) method will be picked, sometimes the bar(int) method.

Environment

javax.el-3.0-b07.jar

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/uel-ri/issues/35
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @glassfishrobot

[glassfishrobot]

@glassfishrobot Commented Reported by cbauer123

[glassfishrobot]

@glassfishrobot Commented cbauer123 said: The root cause is probably that AstMethodArguments#getParamTypes() doesn't seem to be implemented. If overloaded methods are not supported at all, or until this is implemented, an UnsupportedOperationException should be thrown if a class has several methods with the same name and parameter count.

[glassfishrobot]

@glassfishrobot Commented This issue was imported from java.net JIRA UEL-35

[markt-asf]

Reviewing the code that was imported into Jakarta Expression Language, this issue is resolved. The findMethod() methods use a much more comprehensive search algorithm that includes a careful match of parameter types, including allowing for coercion.