Add `JsonNode.canConvertToExactIntegral()` to indicate whether floating-point/BigDecimal values could be converted to integers losslessly

[oguzhanunlu]

Is your feature request related to a problem? Please describe.
DecimalNode might contain a valid integer or long, however DecimalNode.isIntegralNumber doesn't cover such cases and return false from parent JsonNode.isIntegralNumber .

Describe the solution you'd like
Implement DecimalNode.isIntegralNumber to return true if the value can fit into Long or Int

Usage example
DecimalNode.isIntegralNumber(-1) == true

Additional context
I want to use this check during json schema validation so that e.g. a DecimalNode containing an integer smaller than maximum long value can be considered as integer during type validation where schema has integer as type of the property

[cowtowncoder]

Hmmh. No, I don't think that would be good idea, changing semantics in a minor version.

However, there is canConvertToInt() and canConvertToLong() -- would these work?

[oguzhanunlu]

would these work?

Well, sort of, integral check can be accomplished by combining canConvertToLong and another predicate checking if the value has fractional part, since I don't want to interpret e.g. 12.88 as integral, even though it fits into a Long, so that'll do it.

Thanks for the quick reply and feel free to ping me if you'd like a PR for the next major release.

[cowtowncoder]

Ah, yes, checking for missing fractional part is sort of orthogonal, so those methods do not quite match what you are trying to do.

So it might be request for yet-another accessor (hasFractionalPart() or something). I am not sure if there are practical challenges wrt double/float backed nodes (it's trivial for BigDecimal as that is 10-based, not 2-based).

[oguzhanunlu]

so those methods do not quite match what you are trying to do

Yes that's the case and everyone who needs to check fraction will re-implement the same fractional check logic downstream.

An accessor like hasFractionalPart wouldn't change semantics and would come handy for sure, do you think it could be evaluated for a future minor release?

[cowtowncoder]

@oguzhanunlu Sure: I'll change the title and mark this as potentially good first issue for someone to consider implementing; and it could go in a new minor version (2.12 if contribution came quickly enough; 2.13 otherwise).

[bmsbharathi]

Hi
Can I work on this?