https://bz.apache.org/bugzilla/show_bug.cgi?id=65358

Mark Thomas <ma...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|REOPENED                    |RESOLVED

--- Comment #9 from Mark Thomas <ma...@apache.org> ---
Thanks for the test cases. They demonstrate very well the ambiguity that exists
in the current EL 4.0 spec.

The question is, essentially, one of priority of matches. If we look at the
Java language to start with, if a set of parameters could match multiple
methods then the "best" match is chosen based on these checks in this order
(the comparison ends as soon as a rule determines a method is better):
- a non-varargs method is better than a var-args method
- methods that match more exact parameter methods are better
- methods that match more assignable parameters are better
- methods that match fewer parameters using varargs are better

What complicates things for EL is that it adds type coercion.

The tests in the attached patch assume that type coercion is lower priority
than "a non-varargs method beats a var-args method". This is not how the code
was designed. The code was designed to implement:
- a non-varargs method is better than a var-args method
- methods that match more exact parameter methods are better
- methods that match more assignable parameters are better
- methods that match more coercible parameters are better
- methods that match fewer parameters using varargs are better

The next release of the EL spec will contain a clarification to this effect.
Given this bug report, I'll probably add to that text to make clear that
non-varargs still beats varargs even when coercion is used.

Therefore, the matches observed in the tests are as expected because coercing
an Integer to String is preferred to matching an Integer varargs.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to