This behavior can be changed via DeserializationFeature.USE_BIG_DECIMAL_FOR_FLOATS, but that is global setting. Instead, it would perhaps make sense to add a JsonNodeFeature which would only affect JsonNode reading, but would have precedence over DeserializationFeature.
I haven't thought this fully through wrt implementation but this seems like potentially useful thing to have.
Describe your Issue
Due to eager binding of number type when reading
JsonNode
-- basically, decision must be made between reading:Double
vsBigDecimal
(to get either
DoubleNode
orBigDecimalNode
)there are cases where common buffering use cases expose unexpected precision loss -- particular since by default
Double
is used. See, for example:https://github.com/FasterXML/jackson-modules-java8/issues/326
This behavior can be changed via
DeserializationFeature.USE_BIG_DECIMAL_FOR_FLOATS
, but that is global setting. Instead, it would perhaps make sense to add aJsonNodeFeature
which would only affectJsonNode
reading, but would have precedence overDeserializationFeature
.I haven't thought this fully through wrt implementation but this seems like potentially useful thing to have.