On 29 November 2011 16:30, sebb <seb...@gmail.com> wrote:
> On 28 November 2011 16:26, sebb <seb...@gmail.com> wrote:
>> On 28 November 2011 15:55, henrib <hen...@apache.org> wrote:
>>> I added @since 2.1, renamed the Uberspect.getConstructor, removed final for
>>> silent & strict in Interpreter (although Interpreter instances probably
>>> never need to change those at runtime) but there are still 21 clirr errors
>>> that I'm afraid many will consider as show-stoppers for release.
>>
>> Not if they can be shown to be unused by end-users.
>>
>>> I'm pretty sure that no active JEXL user would really be bothered by the 2.1
>>> API modifications - and even less so by the binary incompatibility - but I
>>> don't see how the case can be made...
>>
>> JMeter uses Jexl2 - don't have time to try it now, but I will try
>> tomorrow and see if it is affected by the API breaks.
>
> I've not found any issues - JMeter compiles and tests OK.
> However, JMeter does not use many of the its features.
>
> A better test would be to see what happens with the JUnit test cases from
> 2.0.1.
> Some of these are bound to fail, but if most pass, then that may
> indicate that the API is not too badly broken to release.
I recompiled the 2.0.1 test classes against 2.0.1 source
(unfortunately we did not release a test jar).
An initial test running the 2.0.1 test classes against 2.1_SNAPSHOT
(current 2.0 branch) shows only a few errors:
[junit] Test org.apache.commons.jexl2.ArithmeticTest FAILED -
test*Null*Operand(s)
[junit] Test org.apache.commons.jexl2.IssuesTest FAILED - test73
[junit] Test org.apache.commons.jexl2.UnifiedJEXLTest FAILED -
testPrepareEvaluate, testImmediate, testDeferred
[junit] Test org.apache.commons.jexl2.scripting.JexlScriptEngineTest FAILED
I've not fully investigated all the test failures yet.
JexlScriptEngineTest - to be expected, new engine has new features.
The other tests appear to show failures due behavioural change.
For example:
junit.framework.ComparisonFailure: expected:<Dear [#]{p} Doe;> but
was:<Dear [$]{p} Doe;>
at
org.apache.commons.jexl2.UnifiedJEXLTest.testPrepareEvaluate(UnifiedJEXLTest.java:108)
It's not clear if this is an intentional change or not - is this documented?
It's not yet clear whether the binary API changes have affected the
2.0.1 tests or whether the tests don't rely on those parts of the API.
If the latter, then this may be an indication that the API changes are
unlikely to affect client code.
>>> Any hint/advice/idea ?
>>
>> There are still a few errors that could be fixed.
>> e.g. the visit() changes - would it work to re-introduce dummy
>> deprecated classes ASTFloatLiteral and ASTIntegerLiteral?
>> Or define them in terms of the new classes?
>>
>> JexlArithmetic.strict can be made non-final
>> Likewise the method changes in UnifiedJEXL$Expression could be
>> reverted (and pending changes flagged).
>>
>> I think it's now quite close, apart from the Script interface, which
>> may be allowed.
>>
>>> I've got a migrated-to jexl3 code base ready just in case jexl2 is a
>>> dead-end.
>
> If it does prove necessary, then we should check that there aren't any
> other issues with the API that still need fixing.
>
> Otherwise the process will repeat ...
>
>>> Cheers,
>>> Henrib
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://apache-commons.680414.n4.nabble.com/JEXL-binary-compatibility-tp4114818p4115683.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
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
