SpEL's arithmetic operations should explicitly detect BigInteger/Short/Byte and fall back to double handling for unknown Number subtypes [SPR-9913]

[spring-projects-issues]

Dmitry Paltchoun opened SPR-9913 and commented

OpDivide.getValueInternal(ExpressionState) line: 48
performs Integer division on custom Number types even with precision loss.

Case:
I have a CustomFloat class derived from Number and should operate like a float in SPeL expressions. SPeL performs integer division even the TypeConverter is sets und converts CustomFloat Instances to float.

---

Affects: 3.1.1, 3.1.2

Issue Links:

• Support BigDecimals with SpEL [SPR-9164] #13802 Support BigDecimals with SpEL

Referenced from: commits 92ad02a, d8160b3

[spring-projects-issues]

Chris Beams commented

Hi Andy Clement, care to comment on this? Thanks!

[spring-projects-issues]

Michael Reid commented

I just discovered the same issue -- well similar. It appears that all of the arithmetic operators assume an Integer if the operand is a Number and it isn't a BigDecimal, Double, Float or Long.

I think this happens regardless of what type converters you have because if you extend Number then the arithmetic operators have no need to convert to a supported type? Not too sure on that.

Anyway, I've solved the problem by implementing a custom org.springframework.expression.OperatorOverloader that does the Right Thing.

[spring-projects-issues]

Juergen Hoeller commented

It might a safer assumption to perform double division on unknown Number subtypes, i.e. to rely on Number.doubleValue() which I suppose any custom Number subtype supports, without any loss in precision?

Juergen

[spring-projects-issues]

Michael Reid commented

Agreed. I assumed that it would use doubleValue() in that scenario since it is the most general type to use. OK, if your custom Number type models a long, then this will result in a loss of precision for extremely high values, but I'd suspect the doubleValue() scenario would be most useful to most people.

In any case, for me I will stick with overloading the operators as my needs have changed a bit and I need operate on multiple values so simply extending Number is no longer viable for me.

[spring-projects-issues]

Juergen Hoeller commented

OpDivide falls back to double division now and also checks for BigInteger, delegating to BigInteger.divide(BigInteger) in that case (we've already had analogous code for BigDecimal but not for BigInteger yet).

Juergen

[spring-projects-issues]

Juergen Hoeller commented

I'm also revising OpMultiply, OpPlus and OpMinus for consistent double fallback and explicit BigInteger support, all going into 4.1.2.

Juergen