Long upper limit value

[lissxxxx]

Use Gson

Gson gson = new Gson();
Long a = gson.fromJson("9223372036854775808", Long.class);
System.out.println(a);

=> 9223372036854775807

Use JsonPrimitive

var jp = new JsonPrimitive("9223372036854775808");
Long b = jp.getAsLong();
System.out.println(b);

=> java.lang.NumberFormatException: For input string: "9223372036854775808"

Use Long.valueOf

Long c = Long.valueOf("9223372036854775808");
System.out.println(c);

=> java.lang.NumberFormatException: For input string: "9223372036854775808"

Why is there no error in Gson?
Is this a bug? Or is it a specification?
I want an error to occur.

[lyubomyr-shaydariv]

Most likely a bug. The built-in long/Long type adapter reads the token using nextLong() that is heavily overloaded under the hood and does more than just reading the token as a long integer value: it attempts to parse it as a double value, and then casts it to a long comparing both results (checking for the fraction). The value you provided cannot be checked here:

gson/gson/src/main/java/com/google/gson/stream/JsonReader.java

Line 965 in ceae88b

if (result != asDouble) { // Make sure no precision was lost casting to 'long'.

I want an error to occur.

As a workaround you might want to add the following custom long values type adapter to your GsonBuilder:

final class LongTypeAdapter extends TypeAdapter<Long> {

	private LongTypeAdapter() {}

	private static final TypeAdapter<Long> instance = new LongTypeAdapter().nullSafe();

	static TypeAdapter<Long> get() { return instance; }

	@Override public void write(final JsonWriter out, @Nonnull final Long value) throws IOException { out.value(value); }

	@Override @Nonnull public Long read(final JsonReader in) throws IOException { return Long.parseLong(in.nextString()); }

}

Not sure if this bug can be fixed not breaking the previous versions of Gson.

[Marcono1234]

Fixing this would probably require writing an own Double.parseLong because comparing asDouble.toString() with peekedString could cause false positives, e.g.:

• peekedString = "1e1"
• asDouble.toString() = "10.0"

new BigDecimal(String) cannot be used for parsing either because it would break backward compatibility because it does not support hexadecimal values, e.g. 0xAp2 = 10 * 22 = 40 or the type prefix d/D.

Edit: Or the validation could only be added for integral values which match the pattern described by Long.parseLong. This would catch the case described by this issue, but would not cover some values accepted by Double.parseDouble.