About Was: Dear #{p} Doe; Now: Dear ${p} Doe;
As stated, the issue was that preparing a deferred expression must always
return an immediate (even composite) expression. When preparing "Dear #{p}
${name};" , the immediate ${name} will be evaluated - 'name' is the set of
variables - and the preparation of the inner-deferred #{p} leads to another
immediate ${p} thus the expression "Dear ${p} Doe; " - where the set of
variables is 'p'.
Since asString() must return the stringified form of the expression, it's
pretty essential that this behavior remains as is which is correct.
About JEXL-83 - which is an issue you reported - and its fix which lead to
the JexlThreadedArithmetic, the behavior is documented in the Javadoc @
setLenient():
* <p>This method is <em>not</em> thread safe; it should be called as an
optional step of the JexlEngine initialization code before expression
creation & evaluation.</p>
* <p>As of 2.1, you need a JexlThreadedArithmetic instance for this
call to also modify the JexlArithmetic
* leniency behavior.</p>
The rationale is pretty well documented in the issue itself.
I'd vote for throwing an UnsupportedOperationException with the same message
(or log an error if silent?) and document the change explicitly in the
release notes.
--
View this message in context:
http://apache-commons.680414.n4.nabble.com/JEXL-binary-compatibility-tp4114818p4123859.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
