[
https://issues.apache.org/jira/browse/JEXL-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17353461#comment-17353461
]
Henri Biestro commented on JEXL-347:
------------------------------------
Source of the issue is undefined vs null property/variables handling and
arithmetic operators. Since arithmetic in strict mode disallows null as
arguments, we need an exceptional mechanism for equal and not-equal operators
(a == null must be a valid error less statement). The 'isTernaryProtected'
offered a mitigation but is indeed wrong.
The proper solution is to determine whether we are evaluating the argument(s)
of an arithmetic operator (besides ==/!=) and treat the null vs undefined error
accordingly.
> Missing unsolvable property exception for reference when used with equals
> -------------------------------------------------------------------------
>
> Key: JEXL-347
> URL: https://issues.apache.org/jira/browse/JEXL-347
> Project: Commons JEXL
> Issue Type: Bug
> Reporter: Cameron Samak
> Assignee: Henri Biestro
> Priority: Minor
>
> I expected {code}A.B == 5{code} (with a strict engine and with nothing in the
> context) to result in an unsolvable property exception, but instead the
> result was false.
> I hit this as part of an attempt to upgrade from 3.0 to a recent snapshot. I
> think the change in behavior may be related to the addition of ASTEQNode and
> ASTNENode to isTernaryProtected?
> Is it intentional that equal and not equal are handled this way when e.g.
> greater than or less than are not? If so, is there any option flag that can
> restore the behavior?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
