On handling NaN / +Inf / -Inf wrt java.lang.Double, BigDecimal

[Tatu Saloranta]

(for a background, see https://github.com/FasterXML/jackson-databind/issues/1028)

One problem with Java number handling is that where float and double can handle "non-numeric" values like infinity and general NaN (from division by zero etc), the same is unfortunately not true for BigDecimal.

For example see:

http://stackoverflow.com/questions/28065158/java-bigdecimal-and-double-nan

Given this, there is the problem with possible coercion of JSON values into BigDecimal, and especially the case of having to convert Double/Float representation of NaN or +Infinity or -Infinity.

To me, the main choices appear to be either:

1. Indicate the problem explicitly by throwing an exception (impossible conversion), or

2. Quietly leave the numeric type as-is, and let caller deal with some numbers being BigDecimals, others Doubles.

I can see why (2) may usually be preferable, but am bit concerned about this leading to harder-to-track-down problems, and (1) providing earlier indication of problems.

I may be overstating the issues, however, so if you think (2) makes sense, feel free to say so.

-+ Tatu +-

[mhcom...@gmail.com]

For what it's worth, I did hit a similar bug today.

I have some values coming from a third-party stats library that default in some cases to Double.NaN until they've got enough data to calculate them. Then I have some other stuff which is sending currency-precision floating point in the JSON.

I was feeding it through a Jackson + Jersey stack, and hitting this error, after I had enabled USE_BIG_DECIMAL_FOR_FLOATS for preserving the accuracy of the currency-precision data.

For me, it would definitely help on my side if I had a way to generate JSON with +inf, -inf, NaN, and currency-precision / BigDecimal with a single ObjectMapper registered to Jersey + Grizzly.

Right now I don't think this is possible.

Matthew.

[Tatu Saloranta]

On Tue, Nov 21, 2017 at 4:40 AM, <mhcom...@gmail.com> wrote:
> For what it's worth, I did hit a similar bug today.
>
> I have some values coming from a third-party stats library that default in
> some cases to Double.NaN until they've got enough data to calculate them.
> Then I have some other stuff which is sending currency-precision floating
> point in the JSON.
>
> I was feeding it through a Jackson + Jersey stack, and hitting this error,
> after I had enabled USE_BIG_DECIMAL_FOR_FLOATS for preserving the accuracy
> of the currency-precision data.
>
> For me, it would definitely help on my side if I had a way to generate JSON
> with +inf, -inf, NaN, and currency-precision / BigDecimal with a single
> ObjectMapper registered to Jersey + Grizzly.
>
> Right now I don't think this is possible.

Hard to say for sure, but do note that the issue referred to was
actually fixed, and that `JsonParser` does
have means now to detect `isNaN()` for better handling.

But one problem there is no real way around is that JDK's `BigDecimal`
does not (nor `BigInteger`) concept to map to;
there is no instance that could be considered not-a-number as far as I know.

I think there is at least one remaining open issue so it is possible
you are blocked, but as usual first make sure you
are using an up-to-date Jackson version (2.9.2 ideally; but if 2.8, 2.8.10).

-+ Tatu +-

>
> Matthew.
>
>
> On Monday, November 30, 2015 at 12:38:16 PM UTC-8, Tatu Saloranta wrote:
>>
>> (for a background, see
>> https://github.com/FasterXML/jackson-databind/issues/1028)
>>
>> One problem with Java number handling is that where float and double can
>> handle "non-numeric" values like infinity and general NaN (from division by
>> zero etc), the same is unfortunately not true for BigDecimal.
>> For example see:
>>
>> http://stackoverflow.com/questions/28065158/java-bigdecimal-and-double-nan
>>
>> Given this, there is the problem with possible coercion of JSON values
>> into BigDecimal, and especially the case of having to convert Double/Float
>> representation of NaN or +Infinity or -Infinity.
>> To me, the main choices appear to be either:
>>
>> 1. Indicate the problem explicitly by throwing an exception (impossible
>> conversion), or
>> 2. Quietly leave the numeric type as-is, and let caller deal with some
>> numbers being BigDecimals, others Doubles.
>>
>> I can see why (2) may usually be preferable, but am bit concerned about
>> this leading to harder-to-track-down problems, and (1) providing earlier
>> indication of problems.
>>
>> I may be overstating the issues, however, so if you think (2) makes sense,
>> feel free to say so.
>>
>> -+ Tatu +-
>>
>>
>>

> --
> You received this message because you are subscribed to the Google Groups
> "jackson-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jackson-dev...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.