Thanks, Volkan.
I agree that JSON parsers may have their own number codecs and may not
necessarily rely on Integer.parseInt() or Long.parseLong(). I appreciate
the clarification.
Let me simplify my concern:
I've tried converting a *String to a Number* and loading it into memory,
and my expectation is that it should *occupy the least memory possible*.
Wouldn't that be the ideal approach? If so, does it make sense to have a
utility that helps achieve this efficiently?
On Tue, 1 Apr 2025 at 14:12, Volkan Yazıcı <vol...@yazi.ci> wrote:
> 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.
>
>>
