Skip to content

Update jsoniter number parser implementation to match jsoniter-circe - #3052

Open
kyri-petrou wants to merge 3 commits into
series/3.xfrom
update-jsoniter-number-parser
Open

Update jsoniter number parser implementation to match jsoniter-circe#3052
kyri-petrou wants to merge 3 commits into
series/3.xfrom
update-jsoniter-number-parser

Conversation

@kyri-petrou

Copy link
Copy Markdown
Collaborator

Seems the code we were using is a bit outdated, I updated to match what's also found in jsoniter-circe now

@plokhotnyuk

Copy link
Copy Markdown

I'm going to add JsonRead.readNumber: java.lang.Number that will return the most suitable implementation from java.lang.Integer, java.lang.Long, java.math.BigInteger, java.lang.Float, java.lang.Double, and java.math.BigDecimal in the next minor version of jsoniter-scala (v2.39.0)

@plokhotnyuk

plokhotnyuk commented Jul 9, 2026

Copy link
Copy Markdown

I've released v2.39.0 with JsonRead.readNumber(): java.lang.Number implemented while only for java.lang.Long, java.math.BigInteger, and java.math.BigDecimal as output.

That already speeds up and simplifies circe booster: plokhotnyuk/jsoniter-scala@870a1f1

The next step will be improving JsonRead.readNumber(): java.lang.Number, JsonRead.readBigInt(): BigInt, and JsonRead.readBigDecimal(): BigDecimal implementations to avoid double scanning for small numbers with less than 19 digits.

@kyri-petrou @ghostdogpr Thanks for your support and donations!

Comment on lines +208 to +217
case l: java.lang.Long =>
val asLong = l.longValue()
val asInt = asLong.toInt
// Check if the number can fit in an Int (most common case)
if (asInt.toLong == asLong) Value.IntValue.IntNumber(asInt)
else Value.IntValue.LongNumber(asLong)
case bd: java.math.BigDecimal =>
Value.FloatValue.BigDecimalNumber(bd)
case bi: java.math.BigInteger =>
Value.IntValue.BigIntNumber(bi)

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@plokhotnyuk I'm guessing that you're not planning on returning any other instances of java.lang.Number in the future, is that right?

If that's the case, it might be worth to document this in the scaladoc of readNumber. Or if you're planning on returning any different types, let me know so I can add a default case

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants