Jackson JSON Processor
  1. Jackson JSON Processor
  2. JACKSON-832

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

        Hide
        Tatu Saloranta added a comment -

        Which Jackson version is this in?

        Show
        Tatu Saloranta added a comment - Which Jackson version is this in?
        Hide
        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
        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
        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
        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
        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
        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
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: