My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 7555: AutoBeans: BigInteger parse failure from JSON generated by gson (using numeric value; GWT expects a string)
1 person starred this issue and may be notified of changes. Back to list
Status:  NotPlanned
Closed:  Jul 2012

Sign in to add a comment
Reported by xtremebytes, Jul 26, 2012
Found in GWT Release (e.g. 2.4.0, 2.5.0 RC): 2.4.0

Encountered on OS / Browser (e.g. WinXP, IE8-9, FF7): OS X 10.7 / Chrome 20.0.1132

Detailed description (please be as specific as possible): BigInteger is serialized without double quotes in JSON by gson 2.2.2 ( For example BigInteger testBI = 24923082038902380238 is serialized to JSON as "testBI":24923082038902380238. However, the AutoBeans framework cannot deserialize this number. This problem is, in a way, similar to the bug reported in, where GWT 2.4 cannot deserialize long from JSON.

Workaround if you have one:

Instead of using BigInteger, one can serialize a String representation of it as String testStr = testBI.toString() and then the JSON serialization will be "testStr":"24923082038902380238". AutoBeans can deserialize this as String and then one can read it as BigInteger myBI = new BigInteger(myStr) where myStr is the deserialized String representation of the BigInteger.
Jul 27, 2012
Project Member #1 t.broyer
While technically the JSON generated by GSON is correct, it cannot be parsed in browsers with the native APIs (JSON.parse or eval) because the number cannot be represented as a JavaScript Number.

We actually discussed the BigInteger/BigDecimal case in while fixing  issue 6331 . The difference with longs and dates though is that those used to work in previous versions of GWT (so 2.3 introduced a regression, and we fixed it), whereas BigInteger/BigDecimal never worked with numeric values in the JSON, only strings.

Here's what Brian said about this issue in the review:
> Since BigDecimal / BigInteger didn't work before, I think we can wait on those.
> Backward compatibility when expanding the range is an issue but I'm not sure
> that changing types is sufficient anyway; what about data transfer in the other
> direction? In practice, it might be better to introduce a new field and accept
> either one, which is consistent with what you'd have to do when making a bigger
> data format change.
Summary: AutoBeans: BigInteger parse failure from JSON generated by gson (using numeric value; GWT expects a string)
Status: NotPlanned
Jul 27, 2012
#2 xtremebytes
Okay, that makes sense. So, as a corollary, there is no way to represent or work with any integer in Javascript wider than 64-bits (i.e. size of long in Java)?
Jul 27, 2012
Project Member #3
Double is the only native numeric type in JavaScript, so you can't do exact integers natively beyond 2^53. So even long is not fully implemented; if GSON writes a long that's too big you will silently lose precision (I believe).

My recommendation is that GSON should have a JavaScript compatible mode where it serializes Long/BigInteger/BigDecimal as string, so that a naive JavaScript program can at least display the data and allow users to edit it, but not do math on it. With GWT we can also do math since we emulate Long/BigInteger/BigDecimal.

In theory we could write our own JSON parser to handle this case, but there would be a big loss in speed so most people wouldn't want to use it. It doesn't seem worth it.

Sign in to add a comment

Powered by Google Project Hosting