[ 
https://issues.apache.org/jira/browse/JEXL-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16318098#comment-16318098
 ] 

Dmitri Blinov commented on JEXL-246:
------------------------------------

Well, while I can not say JEXL does not do its job here, I hate the idea of 
having even once an exception logged for a such simple situation. Obviously we 
have a contradiction with overloading. For a JEXL extension writer it would be 
not uncommon to try to overload an operator more than once using different 
signatures for different types. But that would surely lead to ambiguity with 
*null* arguments. The solution I see right now on the developer side is to 
replace all overloaded methods with the only most broad definition like 
{{public JexlOperator selfAdd(Object x, Object y)}}, and do class checking 
inside that method, forwarding further calls to the specific methods from 
there, and blocking *null* arguements. But that kills the idea of using JEXL 
feature for resolving most specific methods, possibly conflicting with default 
JEXL implementation for other types, not speaking of creating messy code. 
Otherwise, if we try to fix it on JEXL side, in case where the first argument 
is *null*, we should try to resolve this only to the overloaded methods whose 
first argument is *Object*, like {{public JexlOperator selfAdd(Object x, T y)}} 
of even unary {{public JexlOperator selfAdd(T y)}}

Null arguments are not suited for type checking, and even if we have had the 
only one overloaded method in Arithmetic class, for example {{public 
JexlOperator selfAdd(Collection x, Object y)}}, it would be pointless to try to 
do anything with *null* collection, except for returning JexlEngine.TRY_FAILED

> Intermittent ambiguous method invocation when processing assignOverload
> -----------------------------------------------------------------------
>
>                 Key: JEXL-246
>                 URL: https://issues.apache.org/jira/browse/JEXL-246
>             Project: Commons JEXL
>          Issue Type: Bug
>    Affects Versions: 3.1
>            Reporter: Dmitri Blinov
>            Assignee: Henri Biestro
>            Priority: Minor
>             Fix For: 3.2
>
>
> Sometimes the simple operator like {code}z += 1{code} when {{z}} has not been 
> defined yet raises an exception 
> {{org.apache.commons.jexl3.internal.introspection.MethodKey$AmbiguousException}}
>  with the following stack trace: 
> {quote}
> ambiguous method invocation: MyArithmetic.selfAdd(null, java.lang.Integer)
> org.apache.commons.jexl3.internal.introspection.MethodKey$AmbiguousException: 
> null
>       at 
> org.apache.commons.jexl3.internal.introspection.MethodKey$Parameters.getMostSpecific(MethodKey.java:540)
>       at 
> org.apache.commons.jexl3.internal.introspection.MethodKey$Parameters.access$000(MethodKey.java:452)
>       at 
> org.apache.commons.jexl3.internal.introspection.MethodKey.getMostSpecificMethod(MethodKey.java:261)
>       at 
> org.apache.commons.jexl3.internal.introspection.ClassMap.getMethod(ClassMap.java:178)
>  
>       at 
> org.apache.commons.jexl3.internal.introspection.Introspector.getMethod(Introspector.java:146)
>       at 
> org.apache.commons.jexl3.internal.introspection.MethodExecutor.discover(MethodExecutor.java:52)
>       at 
> org.apache.commons.jexl3.internal.introspection.Uberspect.getMethod(Uberspect.java:218)
>  
>       at MyUberspect.getMethod(MyUberspect.java:168)
>       at 
> org.apache.commons.jexl3.internal.introspection.Uberspect$ArithmeticUberspect.getOperator(Uberspect.java:413)
>       at 
> org.apache.commons.jexl3.internal.Operators.tryOverload(Operators.java:85) 
>       at 
> org.apache.commons.jexl3.internal.Operators.tryAssignOverload(Operators.java:118)
>  
>       at 
> org.apache.commons.jexl3.internal.Interpreter.executeAssign(Interpreter.java:1292)
>  
>       at 
> org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1102) 
> ....
> {quote}
> The class MyArithmetic contains a couple of overloaded
> {{public JexlOperator selfAdd(T x, Object y)}} methods with the first 
> argument being the desired type {{T}} like {{Appendable}} or {{Collection}} 
> for which the {{+=}} operator is overloaded.
> Obviously in case where the first argument is null and the second argument is 
> an Integer it is not possible to differentiate between {{public JexlOperator 
> selfAdd(Collection x, Object y)}} and {{public JexlOperator 
> selfAdd(Appendable x, Object y)}} but I wonder is there any point in trying 
> to perform {{selfAdd}} on the null variable? What questions me more is that 
> this error is intermittent and sometimes there is an exception and sometimes 
> there is not, so at the moment I have no test case to reproduce. So I think 
> this is a bug.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to