enhance ObjectTypeBinder to works with number type 'int'

[BK-Choi]

• number double or integer number double or integer #525
• integer values of array become a float values integer values of array become a float values #559

the reason I pr this:

• Spring's @RequestBody parses integer params to double values
• this behavior is not right when you parse HTTP request body parameters.
  • Web App never knows whether the parameter type is wrong or not
  • int should be parsed int, not double
• RFC-4627 and JSON defines type int,
  so I hope this PR does not violate any rules.

related issues

• number double or integer number double or integer #525
• integer values of array become a float values integer values of array become a float values #559

[googlebot]

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).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

---

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If you signed the CLA as a corporation, please let us know the company's name.

[BK-Choi]

CLA signed (individual)

[googlebot]

CLAs look good, thanks!

[jobh]

A few issues. Most importantly, check for integer overflow (NumberFormatException), and exponent notation ("e" in addition to "."). Maybe use Long instead of Integer?

Now, even Long and Double may overflow, in the latter case losing precision. Also, doubles typically lose precision when converting from decimal, even if not overflowing. I think the best option would be to return BigDecimal instead of Double, and BigInteger instead of Integer. Opinions?

[SergeyKoval]

When it will be merged to muster and released?

[BK-Choi]

@jobh
my opinion is,

• integer should be ok with common number use
• Long sounds good to me
• BigDecimal sounds not good
  • waste of memory and time for some people; performance issue
  • maybe what we need is an option for BigDecimal parsing.
• exponential expression
  • oh nice pointing out. thank you.

I can change the "integer" code to "long" one anytime,
however one GSON contributor said GSON is never going to support integer(or long).
(couldn't find the reference, short-term-memory :( )
So, the contributors' affirmitive opinion first, then I can use my time to fix codes.

[SergeyKoval]

I believe not only me wait for this fix...

[inder123]

@swankjesse Looks like a reasonable change to me. I plan to merge it in the next few days unless I hear a concern from you.

[swankjesse]

Changing the type of a thing is extremely incompatible. If we merge this, nobody will be able to upgrade safely.

[swankjesse]

Specifically, this is not at all backwards-compatible.

[SergeyKoval]

@swankjesse does it mean that in gson int will be never converted to correct type if it is not specified in end object directly?

[swankjesse]

RFC-4627 and JSON defines type int,
so I hope this PR does not violate any rules.

Though the label int is used to describe the number type, an int is not a standalone value. That’s number and JSON doesn’t offer different types depending on whether a .0 is in the encoded form.

 value = false / null / true / object / array / number / string 

Making .0 significant would be not unlike making whitespace significant.

[SergeyKoval]

@swankjesse but with current implementation if we deserialize json and serialize it back we will get different jsons. I believe it is not an expected behavior.

[jobh]

This class looks like it was designed for the purpose -

com.google.gson.internal.LazilyParsedNumber

• it is an abstract number (like JSON), not a specific type
• it roundtrips perfectly, since the string rep is stored
• converts to whatever is needed, even BigDecimal etc

[BK-Choi]

@swankjesse
In GSON world, you said that 0 and 0.0 are the same.
So no need to fix this.
please close this PR (or should I?)

@jobh
thank you!