Fix #2817: Add precision check to JsonTreeReader.nextInt() and nextLong() by ErnestHysa · Pull Request #3029 · google/gson

ErnestHysa · 2026-05-31T17:40:03Z

Description

When a double value is stored in a JsonPrimitive, calling or should throw to be consistent with behavior, instead of silently truncating the value.

Issue

Issue #2817 reports that correctly throws when trying to read a double as an int/long, but silently casts the value.

JsonReader behavior (correct):

JsonTreeReader behavior (buggy):

Fix

This fix adds the same precision validation that has:

now checks if the double value can be exactly represented as an int, and throws if precision would be lost
similarly checks for precision loss

Changes

JsonTreeReader.java: Modified and to validate that the stored number can be exactly represented as the requested type without precision loss
JsonTreeReaderTest.java: Added two test cases to verify the fix

Testing

Added unit tests to verify that and throw when the stored value is a double that would lose precision when cast.

Fixes #2817

Both Gson.fromJson and JsonParser.parseReader accepted trailing data after a top-level null because the trailing-data check was skipped when the parsed element was null. Changed assertFullConsumption() in Gson.java to always check for END_DOCUMENT (removing the 'obj != null' guard), and changed the check in JsonParser.parseReader() to unconditionally verify END_DOCUMENT (removing the '!element.isJsonNull()' guard).

…nextLong() When a double value is stored in a JsonPrimitive, calling nextInt() or nextLong() should throw NumberFormatException to be consistent with JsonReader behavior, instead of silently truncating the value. This fix adds the same precision validation that JsonReader has: - nextInt() now checks if the double value can be exactly represented as an int, and throws if precision would be lost - nextLong() similarly checks for precision loss Fixes inconsistency where JsonReader fails but JsonTreeReader silently casts the value.

google-cla · 2026-05-31T17:40:13Z

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

ErnestHysa · 2026-06-05T12:29:32Z

CLA check looks like it didn't pick up my signature — I'm re-checking the linked Google account. The fix itself is ready for review on the code side; will update the CLA status as soon as it's cleared on the Google side.

Marcono1234 · 2026-06-05T13:36:17Z

  private static void assertFullConsumption(Object obj, JsonReader reader) {
    try {
-      if (obj != null && reader.peek() != JsonToken.END_DOCUMENT) {
+      if (reader.peek() != JsonToken.END_DOCUMENT) {


This accidentally includes changes from your other PR?

Marcono1234 · 2026-06-05T13:36:22Z

      JsonReader jsonReader = new JsonReader(reader);
      JsonElement element = parseReader(jsonReader);
-      if (!element.isJsonNull() && jsonReader.peek() != JsonToken.END_DOCUMENT) {
+      if (jsonReader.peek() != JsonToken.END_DOCUMENT) {


This accidentally includes changes from your other PR?

eamonnmcmanus · 2026-06-05T14:23:52Z

Thanks for this! It's a behaviour change, but I think JsonTreeReader is relatively little used, and this is something of a corner case anyway, so that's probably OK.

Something seems to have happened to the PR description. There's a lot of missing text, "calling or should throw to be consistent with behavior" and the correct and incorrect examples. Can you fix that? Along with the UnusedVariable finding.

Marcono1234

Feel free to consider my comments only as suggestions, though I hope they are helpful.

@eamonnmcmanus, in #2031 (comment) you had concerns regarding related changes. But that PR changed JsonPrimitive behavior while this here only changes JsonTreeReader, so maybe this PR here is not as problematic?

Marcono1234 · 2026-06-05T15:05:36Z

+          }
+        }
+      } else {
+        result = Long.parseLong(primitive.getAsString());


Maybe this could instead still call getAsLong()?

Suggested change

result = Long.parseLong(primitive.getAsString());

result = primitive.getAsLong();

Marcono1234 · 2026-06-05T15:06:07Z

+          }
+        }
+      } else {
+        result = Integer.parseInt(primitive.getAsString());


Maybe this could instead still call getAsInt()?

Suggested change

result = Integer.parseInt(primitive.getAsString());

result = primitive.getAsInt();

Marcono1234 · 2026-06-05T15:06:32Z

+        result = Long.parseLong(primitive.getAsString());
+      }
+    } else {
+      throw new IllegalStateException("Unexpected token: " + o);


Might be better to use AssertionError to make it clear that this should be unreachable.

Suggested change

throw new IllegalStateException("Unexpected token: " + o);

throw new AssertionError("Unexpected token: " + o);

Marcono1234 · 2026-06-05T15:06:37Z

+        result = Integer.parseInt(primitive.getAsString());
+      }
+    } else {
+      throw new IllegalStateException("Unexpected token: " + o);


Might be better to use AssertionError to make it clear that this should be unreachable.

Suggested change

throw new IllegalStateException("Unexpected token: " + o);

throw new AssertionError("Unexpected token: " + o);

Marcono1234 · 2026-06-05T15:22:47Z

+        if (number instanceof Long || number instanceof Integer) {
+          result = number.longValue();
+        } else {


This will probably need explicit handling for BigInteger and BigDecimal (for nextLong() only) because values near Long.MAX_VALUE cannot be represented exactly by double.
So with your changes this would break behavior which was working previously for such values.

Maybe what you could do is:

For BigDecimal

call BigDecimal#longValueExact()

catch the ArithmeticException and wrap it in a descriptive NumberFormatException

For BigInteger

check bitLength() >= 64 and throw NumberFormatException in that case
Cannot call BigInteger#longValueExact() because it seems that method was only added recently to Android, for an API Level higher than Gson's minimum one. But maybe add a TODO comment to use that method in the future?
See also Issue 1994 #2031 (comment).

call BigInteger#longValue()

This is just a suggestion though. Maybe there are other ways to solve this as well.

Marcono1234 · 2026-06-05T23:13:41Z

+        Number number = primitive.getAsNumber();
+        if (number instanceof Long || number instanceof Integer) {
+          result = number.longValue();
+        } else {


Similarly, might also need special handling for LazilyParsedNumber since that might also be common inside JsonPrimitive.

Maybe LazilyParsedNumber would need a new longValueExact() for that, maybe something like this?

public long longValueExact() { try { return Long.parseLong(value); } catch (NumberFormatException ignored) { BigDecimal bigDecimal = asBigDecimal(); try { return bigDecimal.longValueExact(); } catch (ArithmeticException arithmeticException) { NumberFormatException e = new NumberFormatException(arithmeticException.getMessage()); e.initCause(arithmeticException); throw e; } } }

(but might have to catch the NumberFormatException here then, wrap it and include locationString()?)

ErnestHysa added 2 commits May 31, 2026 16:56

Marcono1234 reviewed Jun 5, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix #2817: Add precision check to JsonTreeReader.nextInt() and nextLong()#3029

Fix #2817: Add precision check to JsonTreeReader.nextInt() and nextLong()#3029
ErnestHysa wants to merge 2 commits into
google:mainfrom
ErnestHysa:fix/2817-jsonTreeReader-precision-check

ErnestHysa commented May 31, 2026

Uh oh!

google-cla Bot commented May 31, 2026

Uh oh!

ErnestHysa commented Jun 5, 2026

Uh oh!

Marcono1234 Jun 5, 2026

Uh oh!

Marcono1234 Jun 5, 2026

Uh oh!

eamonnmcmanus commented Jun 5, 2026

Uh oh!

Marcono1234 left a comment

Uh oh!

Marcono1234 Jun 5, 2026

Uh oh!

Marcono1234 Jun 5, 2026

Uh oh!

Marcono1234 Jun 5, 2026

Uh oh!

Marcono1234 Jun 5, 2026

Uh oh!

Marcono1234 Jun 5, 2026

Uh oh!

Marcono1234 Jun 5, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

	result = Long.parseLong(primitive.getAsString());
	result = primitive.getAsLong();

	result = Integer.parseInt(primitive.getAsString());
	result = primitive.getAsInt();

	throw new IllegalStateException("Unexpected token: " + o);
	throw new AssertionError("Unexpected token: " + o);

Conversation

ErnestHysa commented May 31, 2026

Description

Issue

Fix

Changes

Testing

Uh oh!

google-cla Bot commented May 31, 2026

Uh oh!

ErnestHysa commented Jun 5, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

eamonnmcmanus commented Jun 5, 2026

Uh oh!

Marcono1234 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants