Details
- Type:
Bug
- Status:
Closed
- Priority:
Major
- Resolution: Fixed
- Affects Version/s: 1.9
-
- Component/s: ObjectMapper
- Labels:
- Number of attachments :
Description
We used this JSON for testing{ "magicNumber": 9223372036854775808, }
the number was changed according to JSON column
this class was used:
public class User {
private Long _magicNumber;
public Long getMagicNumber(){return _magicNumber;}
public void setMagicNumber(Long m) {_magicNumber = m;}
}
the type of _magicNumber was changed according to range check (Long for check outside Long range, Double for check outside Double...)
issues:
JSON JAVA
-9223372036854775809 9223372036854775807 (Long.MIN_VALUE)
9223372036854775808 -9223372036854775808 (Long.MAX_VALUE+1)
1.4e-46 0 (Float.MIN_VALUE/10)
1.7976931348623157e309 Infinity (Double.MAX_VALUE*10)
4.9e-325 0 (Double.MIN_VALUE/10)
Activity
Added Junit test for bug
1.9.6 version of jackson parser was used
Ah. Overflow is for some reason only tested for ints. I can reproduce failing case for long easily.
And code that SHOULD check this, in parser itself, sayeth:
} else if ((_numTypesValid & NR_BIGINT) != 0) {
// !!! Should check for range...
_numberLong = _numberBigInt.longValue();
... indeed.
Fixed this in 2.0 trunk; will merge fix in 1.9.6 tonight.
Not sure what to do with float/double, however; they are more difficult to handle. And current behavior may be acceptable (since it does not change sign), although ideally in both cases we would be able to use BigDecimal and detect over-/underflow. But doing this without significant additional overhead for common case may be difficult to achieve.
Ok: added unit test for case of Long value overflows; fixed the underlying checks.
Open to suggestions for good improvements for double case (and perhaps)
Ok: I'll mark this completed, since integral checks exist. I also don't quite know if and what to do with floating-point values; so let's open a new issue with additional improvements, as necessary.
Which Jackson version is this in?