On Tue, Nov 21, 2017 at 4:40 AM, <[email protected]> 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
