📜 Description

JsonObjectDeserializer.nextNumber() (used when deserializing arbitrary/unknown JSON into a generic Map/List tree) decided whether a JSON number was an int or a double by calling reader.nextInt() and catching the NumberFormatException it throws for every non-integer value, then falling back to reader.nextDouble(). Because NumberFormatException fills in a stack trace, every floating-point value (timestamps, measurements, …) paid the cost of a thrown exception.

This replaces the exception-driven typing by reading the literal as a double once and narrowing it back to an int only when the value is integral and fits:

final double value = reader.nextDouble();
final int intValue = (int) value;
if (intValue == value) {
  return intValue;
}
return value;

Return types are intentionally unchanged — Integer for values that are integral and fit an int, Double otherwise (fractional or out of int range). This matters: callers read integers back out of the generic tree and cast them (e.g. ReplayRecording casts rrweb source/type values to Integer/int), and defined fields such as MeasurementValue.value and context values like thread.id would otherwise change on the wire (4 → 4.0). Only the internal path to those same results changes; no exceptions are thrown.

Note that reader.nextDouble() is used rather than Double.parseDouble(reader.nextString()): it reuses the reader's already-buffered numeric token instead of materializing a String and re-parsing it, and it keeps the reader's non-finite guard, so a literal that overflows to infinity (1e400) is still rejected as malformed JSON instead of being stored as Infinity. (NaN/Infinity literals never reach this method — the reader tokenizes them as STRING, not NUMBER, even in lenient mode.)

For context: Gson and Moshi both return Double for all numbers when deserializing arbitrary JSON. We deliberately do not match that here, because the generic tree feeds code that depends on the int/double distinction.

One deliberate narrowing versus the old code: the previous reader.nextLong() fallback is gone, so nextNumber() no longer returns Long. Integers beyond int range were already returned as Double by the old path (nextInt() failed, nextDouble() then succeeded), so this only removes a branch that was unreachable for well-formed numbers; values above 2^53 still lose precision exactly as before.

💡 Motivation and Context

Part of JAVA-536 (optimize vendored libraries for startup performance). While benchmarking whether the vendored gson JSON streaming code should be replaced with moshi, this exception-based number typing showed up as a self-inflicted cost. The moshi comparison itself concluded a swap is not worthwhile (the vendored gson engine is as fast or faster, and moshi would add Okio + churn ~80 files); full data is in JAVA-536.

📈 Benchmark

Parsing one sentry_event.json into a generic object tree, median ms per 1000 iterations (desktop JVM, 5 warmup rounds, median of 10):

Removing the exceptions roughly halves the number-typing work in isolation. End-to-end the win is more modest (~5%), because JsonObjectDeserializer's token-stack allocations dominate that path; payloads with many floating-point values (e.g. profiling measurements) benefit more.

Numbers were measured with a local micro-benchmark (not committed, to keep this PR to the fix + tests); the before/after was obtained by stashing the change and re-running. Methodology: preload the payload into memory, parse it nextObjectOrNull ×1000 per timed run, 2–5 warmup rounds discarded, report the median. The benchmark measured the Double.parseDouble(nextString()) variant; the committed nextDouble() version avoids an additional String allocation and re-parse per number, so it should be at least as fast. Full moshi-vs-gson comparison data is in JAVA-536.

💚 How did you test it?

• Full sentry unit test suite passes (3434 tests, 0 failures).
• Added edge-case tests to JsonObjectDeserializerTest covering negative ints/doubles, integral vs. fractional exponent notation (1e2 → Integer, 2.5e-3 → Double), whole-valued decimals (1.0 → Integer), integers beyond int range (→ Double, never Long), the Int.MAX_VALUE boundary, and a literal that overflows to infinity (1e400 → rejected) — locking in the return types that must not change.

📝 Checklist

• I added GH Issue ID & Linear ID
• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• I updated the wizard if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.