fix: Preserve integral Number type in toJsonTree for byte/short/int

[daguimu]

Problem

When using toJsonTree with byte, short, or int types, the resulting JsonPrimitive stores a Long instead of the expected Byte, Short, or Integer. This is a regression introduced by commit 3e3266c.

Root Cause

The BYTE, SHORT, and INTEGER type adapters call out.value(value.byteValue()), out.value(value.shortValue()), and out.value(value.intValue()) respectively. Since JsonWriter only has value(long) (no value(int)), Java auto-widens the primitive to long. In JsonTreeWriter, value(long) creates new JsonPrimitive(long), storing a Long regardless of the original type.

Fix

Cast the narrowed primitive to Number before passing to value(). This triggers autoboxing to Byte/Short/Integer and causes Java to resolve value(Number) instead of value(long). JsonTreeWriter.value(Number) preserves the actual Number type in the JsonPrimitive. For regular JsonWriter, value(Number) produces identical text output.

Tests Added

• testToJsonTreePreservesIntegralType — verifies that toJsonTree preserves:
  • Byte type for byte/Byte.class
  • Short type for short/Short.class
  • Integer type for int/Integer.class
  • Long type for long/Long.class (unchanged, regression guard)
  • Correct target type after narrowing conversion (e.g., Double → Integer, Long → Byte)

Impact

Only affects code paths using JsonTreeWriter (i.e., toJsonTree). Regular JSON string serialization via toJson is unaffected since value(Number) and value(long) produce the same text output. All 4587 existing tests pass.

Fixes #2680

[google-cla]

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

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[Marcono1234]

Thanks for the PR, for what it's worth, there is already an existing (though by now slightly outdated) PR: #2814

I guess the maintainers will decide which one they prefer. So feel free to keep your PR here open.

[eamonnmcmanus]

Thanks for the PR, for what it's worth, there is already an existing (though by now slightly outdated) PR: #2814

I guess the maintainers will decide which one they prefer. So feel free to keep your PR here open.

Sorry, I'm not sure why we didn't get around to merging #2814. If that one and this are functionally identical (are they?) then we might go with this one just because #2814 would have to be brought up to date.

I'm testing it against all of Google's internal tests, which will take a little while.

[Marcono1234]

#2814 also tried to keep reusing the existing Number object if it already has the correct type, e.g. use Integer as is instead of doing (Number) integer.intValue(). Not sure if that provides any performance improvement though. So I guess it can be omitted.

[Marcono1234]

The other alternative would be to revert 3e3266c (as mentioned also in #2814); maybe that change was not worth it, and would have only mattered for rare corner cases.