Sathish, please see my response below.
On Tue, Apr 1, 2025 at 7:58 AM Sathish Kumar Thiyagarajan <
sathishkumar.thiyagara...@gmail.com> wrote:
> However, *Jackson (and most JSON parsers) default to Integer for whole
> numbers* because they rely on Integer.parseInt(String), which is a safe
> fallback for most cases.
>
AFAIK, almost all JSON parsers use their own number codecs; i.e., encoders
and decoders. In the context of Jackson, `new ObjectMapper().readValue("1",
Number.class)` ends up in
`com.fasterxml.jackson.core.io.NumberInput::parseInt`, not
`Integer::parseInt`. There are multiple reasons for such libraries to roll
out their own number codecs; performance, matching the internal string
representation of library's choice, etc. It is very unlikely adding a
`Number::parseNumber` will bring any benefit to such use cases.
[Quoting from another post
<https://mail.openjdk.org/pipermail/loom-dev/2025-March/007446.html>] It is
better to frame feedback in the form of *"I’ve tried this, and run into the
following problem ..."* At the very least it helps us see what problems
people actually run into as opposed to what problems people speculate that
they or others may run into.
>
