Waldemar Horbowicz created JEXL-156:
---------------------------------------
Summary: BigDecimal does not take precedence in arithmetic
operations
Key: JEXL-156
URL: https://issues.apache.org/jira/browse/JEXL-156
Project: Commons JEXL
Issue Type: Bug
Affects Versions: 2.1.1
Reporter: Waldemar Horbowicz
According to javadoc on org.apache.commons.jexl2.JexlArithmetic for arithmetic
operations when either operand is BigDecimal both are coerced to BigDecimal to
perform operation.
During formula evaluation however operation is calculated on BigDecimals only
if both operands are BigDecimal. If one of them is float(double) calculations
are done on Double.
Example:
Given method
Object evaluate(String formula) {
return new JexlEngine().createExpression().evaluate(new MapContext()) ;
}
evaluate("463.0B * 0.1") returns 46.300000000000004 of type java.lang.Double
while
evaluate("463.0B * 0.1B") returns 46.30 of type java.math.BigDecimal
>From my perspective this is a bug as operation is performed on type with less
>precise result causing as in above example floating point representation error
>for quite trivial calculation.
While reporting this bug I also noticed similar downgrade for operations on
BigDecimal and integral values :
evaluate("463.0B * 1") returns java.lang.Integer
evaluate("463.0B * 1L") returns java.lang.Long
while
evaluate("463.0 * 1") returns java.lang.Double
evaluate("463.0 * 1L") returns java.lang.Double
Fortunately for results that cannot be expressed as integral value BigDecimal
is returned so precision of calculations is not lost.
>From what I have seen in sources this issue should not occur in JEXL3 however
>it is not yet released.
I'm willing to contribute a patch for that If this would result in release of
JEXL2 with a fix in the near future. Would that be possible?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
