LazilyParsedNumber in gson-2.1 breaks code

[Moritz Post]

Hi all

I have just upgrade to gson 2.1 and am now experiencing problems with
the way numbers are deserialized. In gson 1.7 a json list of different
types would serialize to an Object list with the types of the elements
reflecting their json primitve types. Example:

json: ["a", 1]

would turn into the following in 1.7 (examplified writing):

java: java.util.List of Object -> [String("a"), Integer(1)]

in 2.1 this turns into:

java: java.util.List of Object -> [String("a"), LazilyParsedNumber(1)]

As a result the second element of number 1 can not be cast to (int)
anymore nore can it be autoboxed. I woul expect that gson does not
parse into internal datatypes when deserializing.

In addition the class LazilyParsedNumber does not implements hashCode/
equals. In consequence you can not use the lazy value when writing
tests and trying to verify that Integer(1) and LazilyParsedNumber(1)
are actually equal values.

Any clarification on that matter would be appreciated. Also a solution
to not have numbers parsed to LazilyParsedNumber would be great.

Regards
Moritz Post

[Jesse Wilson]

Just call intValue() on the returned number?

[Moritz Post]

On Feb 7, 4:26 am, Jesse Wilson <jessewil...@google.com> wrote:
> Just call intValue() on the returned number?

That is what i am currently doing but there are two things flawed with
that approach:

1. There is no hashCode/Equals on that class. It is not possible to
assert any values with the LazilyParsedNumber. A proper implementation
would compare to the xxValue() where xx is the type of the wrapped
number.

2. Producing the LazilyParsedNumber spills api from gson into model
objects that should not be aware of the gson layer. Yes, one can just
assume it to be of type Number but it still feels awkward.

Regards
Moritz Post