Add JsonNodeFeature.USE_BIG_DECIMAL_FOR_FLOATS to allow overriding DeserializationFeature.USE_BIG_DECIMAL_FOR_FLOATS

[cowtowncoder]

Describe your Issue

Due to eager binding of number type when reading JsonNode -- basically, decision must be made between reading:

1. Slightly faster, but potentially lossy Double vs
2. Bit slower but unlimited range/precision BigDecimal

(to get either DoubleNode or BigDecimalNode)

there are cases where common buffering use cases expose unexpected precision loss -- particular since by default Double is used. See, for example:

FasterXML/jackson-modules-java8#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 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.

[cowtowncoder]

@JooHyukKim If you looking for things to work on, here is one.

[pjfanning]

Can we agree how the DeserializationFeature.USE_BIG_DECIMAL_FOR_FLOATS and JsonNodeFeature.USE_BIG_DECIMAL_FOR_FLOATS enable/disable state interacts?

Can I suggest?

DeserializationFeature	JsonNodeFeature	Overall Effect
true	true	true
true	false	true
true	undefined (default)	true
false (default)	true	true
false (default)	false	false
false (default)	undefined (default)	false (default)

So if either DeserializationFeature.USE_BIG_DECIMAL_FOR_FLOATS or JsonNodeFeature.USE_BIG_DECIMAL_FOR_FLOATS is true, then for JsonNode calculation, USE_BIG_DECIMAL_FOR_FLOATS is true.

[JooHyukKim]

I concur @pjfanning

[cowtowncoder]

Actually: one thing to consider -- JsonNodeFeatures have 3 states: enabled, disabled, undefined.

So we should have six states, but basically if JsonNodeFeature is "enabled" or "disabled", that takes effect as-is; otherwise ("undefined" / default), DeserializationFeature.USE_BIG_DECIMAL_FOR_FLOATS setting (which only has "enabled" / "disabled").

Ability to have "undefined" (or "default") is one improvement new EnumFeature, JsonNodeFeature (and... upcoming DateTimeFeature?) has that is nice.

[pjfanning]

@cowtowncoder I added undefined in #4801 (comment) -- does this make sense?

[cowtowncoder]

@pjfanning almost but not quite (unless I misread it). What I think should happen is that since JsonNodeFeature.USE_BIG_DECIMAL_FOR_FLOATS is more specific, it should have precedence. Put it another way, logic can be expressed as:

1. Default setting comes from DeserializationFeature.USE_BIG_DECIMAL_FOR_FLOATS: true or false -- this is global setting for all datatypes
2. JsonNodeFeature.USE_BIG_DECIMAL_FOR_FLOATS may override this, but only if it has been explicitly set astrueorfalse`.

So I think row 2 should be changed from

DeserializationFeature	JsonNodeFeature	Overall Effect
true	false	true

into

DeserializationFeature	JsonNodeFeature	Overall Effect
true	false	false

and otherwise table is ok.

Does this make sense?

[JooHyukKim]

Okay final?

DeserializationFeature	JsonNodeFeature	Overall Effect
true	true	true
true	false	false
true	undefined (default)	true
false (default)	true	true
false (default)	false	false
false (default)	undefined (default)	false (default)

[JooHyukKim]

Came up with #5058, seems easier than I thought 🤔