commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Narendran MC <>
Subject [jexl] Problem with the JexlArithmetic - divide and equals
Date Sun, 08 May 2011 18:57:02 GMT
Hello Jexl Users,

First, thanks for developing this, its very useful and simple to use.

I was planning to use it for one of my projects, but I am running into few
issues. I am using the latest build (2.0.2-Snapshot) - the version in which
JexlArithmetic takes MathContext to solve the divide problem. I see couple
of issues:

1. MathContext allows one to control the precision and rounding mode, but
not the scale. Without that comparison using the result any operation
(multiply/divide) would fail.
2. There seems to be bug in JexlArithmetic equals method. The intend seems
to be to use compareTo when BigDecimal, but the code handling the case when
only one of them is BigDecimal. Here is the snippet

        } else if (left.getClass().equals(right.getClass())) {
            return left.equals(right);
        } else if (left instanceof BigDecimal || right instanceof
BigDecimal) {
            return toBigDecimal(left).compareTo(toBigDecimal(right)) == 0;
So, when both the operands are BigDecimal, it does equals, which is trouble.
The instanceOfBigDecimal check should go above the class equals check.

I feel the bigger problem is any comparison without applying scale would
fail. Here is the example

    String expStr1 = "result == salary/month * work.percent/100.00";
    Expression exp1 = engine.createExpression(expStr1);
    JexlContext ctx = new MapContext();
    ctx.set("result", new BigDecimal("9958.33"));
    ctx.set("salary", new BigDecimal("119500.00"));
    ctx.set("month",  new BigDecimal("12.00"));
    ctx.set("percent", new BigDecimal("100.00"));

This always returns 'false', as the right operand computes
to 9958.333333333333333333333333333333, which is not equals to or compares
to 9958.33.

I think the JexlArithmetic should take the scale and the equals method
should apply the scale on both the left and right operands and then perform
the check.

Let me know, if this doesn't make any sense, and missing something obvious.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message