commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From henrib <>
Subject Re: [JEXL] binary compatibility
Date Wed, 30 Nov 2011 17:11:46 GMT

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 @
     * <p>This method is <em>not</em> thread safe; it should be called as
optional step of the JexlEngine initialization code before expression
creation &amp; 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:
Sent from the Commons - Dev mailing list archive at

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message