Jackson JSON Processor

Made numeric range(Long, Integer, Float) check on the serializer and got some Issues

Details

  • Number of attachments :
    1

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

Ascending order - Click to sort in descending order
Hide
Permalink
Tatu Saloranta added a comment -

Which Jackson version is this in?

Show
Tatu Saloranta added a comment - Which Jackson version is this in?
Hide
Permalink
Jan Jan added a comment -

Added Junit test for bug

1.9.6 version of jackson parser was used

Show
Jan Jan added a comment - Added Junit test for bug 1.9.6 version of jackson parser was used
Hide
Permalink
Tatu Saloranta added a comment -

Ah. Overflow is for some reason only tested for ints. I can reproduce failing case for long easily.

Show
Tatu Saloranta added a comment - Ah. Overflow is for some reason only tested for ints. I can reproduce failing case for long easily.
Hide
Permalink
Tatu Saloranta added a comment -

And code that SHOULD check this, in parser itself, sayeth:

} else if ((_numTypesValid & NR_BIGINT) != 0) {
// !!! Should check for range...
_numberLong = _numberBigInt.longValue();

... indeed.

Show
Tatu Saloranta added a comment - And code that SHOULD check this, in parser itself, sayeth: } else if ((_numTypesValid & NR_BIGINT) != 0) { // !!! Should check for range... _numberLong = _numberBigInt.longValue(); ... indeed.
Hide
Permalink
Tatu Saloranta added a comment -

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.

Show
Tatu Saloranta added a comment - 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.
Hide
Permalink
Tatu Saloranta added a comment -

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)

Show
Tatu Saloranta added a comment - 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)
Hide
Permalink
Tatu Saloranta added a comment -

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.

Show
Tatu Saloranta added a comment - 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.

People

  • Assignee:
    Tatu Saloranta
    Reporter:
    Jan Jan
Vote (0)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved: