<div dir="ltr"><p class="gmail-">Thanks, Volkan.</p>
<p class="gmail-">I agree that JSON parsers may have their own number codecs and may not necessarily rely on <code>Integer.parseInt()</code> or <code>Long.parseLong()</code>. I appreciate the clarification.</p>
<p class="gmail-">Let me simplify my concern:</p>
<p class="gmail-">I've tried converting a <strong>String to a Number</strong> and loading it into memory, and my expectation is that it should <strong>occupy the least memory possible</strong>. Wouldn't that be the ideal approach? If so, does it make sense to have a utility that helps achieve this efficiently?<br><br></p></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, 1 Apr 2025 at 14:12, Volkan Yazıcı <<a href="mailto:volkan@yazi.ci">volkan@yazi.ci</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Sathish, please see my response below.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 1, 2025 at 7:58 AM Sathish Kumar Thiyagarajan <<a href="mailto:sathishkumar.thiyagarajan@gmail.com" target="_blank">sathishkumar.thiyagarajan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><p>However, <strong><font color="#cc0000">Jackson (and most JSON parsers) default to <code>Integer</code> for whole numbers</font></strong> because they rely on <code>Integer.parseInt(String)</code>, which is a safe fallback for most cases.</p></div></blockquote><div>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.</div><div><br></div><div>[Quoting from <a href="https://mail.openjdk.org/pipermail/loom-dev/2025-March/007446.html" target="_blank">another post</a>] It is better to frame feedback in the form of <i>"I’ve tried this, and run into the following problem ..."</i> 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.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>