BigDecimal loses precision on round trip

* What steps will reproduce the problem?

Try executing the following:

    BigDecimal x = new BigDecimal("1.00");
    String json = new Gson().toJson(x);
    BigDecimal y = new Gson().fromJson(json, BigDecimal.class);
    assertEquals(x, y);

* What is the expected output? What do you see instead?

x and y should be equal, but they aren't.  The assertion fails with:

    expected: <1.00> but was: <1.0>

Precision is lost: x.precision() is 3, but y.precision() is 2.  This
seems to be happening because the JsonParser.JsonNumber() method is
trying to optimize the number representation -- see the clause beginning
with "if (exppart != null)".  Because there is no exponent, it chooses
a Double, which loses the information on how many digits of precision
are present.

This problem doesn't happen for numbers with exponents.  Parsing "1.00"
yields a BigDecimal with precision 2, but parsing "1.00E+5" does produce
a BigDecimal with precision 3.

Since BigDecimal is carefully designed to preserve information in
its string representation (see the Javadoc for BigDecimal.toString()),
and its equals() method considers "1.0" and "1.00" to be unequal,
it would be nice to carry this through.  I believe this would just be
a matter of always using BigDecimal as the representation in the parser,
regardless of whether "exppart" or "fracpart" are present, and converting
to another number type only when you know what kind of number is being
requested.

* What version of the product are you using? On what operating system?

I'm using Gson 1.2.3 on Linux.

Original issue reported on code.google.com by p...@zesty.ca on 18 Nov 2008 at 12:51

discomarathon / google-gson

BigDecimal loses precision on round trip #72