Adversaries might be able to forge data which can be abused for DoS attacks.
These classes are already writing a replacement JDK object during serialization
for a long time, so this change should not cause any issues.
Gson does not actually use the specified LongSerializationPolicy but instead
uses type adapters which emulate the behavior. However, previously Gson's
implementation did not match LongSerializationPolicy regarding null handling.
Because it is rather unlikely that LongSerializationPolicy has been used on
its own, this commit adjusts its implementation to match Gson's behavior
(instead of the other way around).
* Object and Number type adapters number deserialization can be configured
* Change wording of ToNumberStrategy documentation
* Use inline links in doc sparingly
If the element has already been linked before, don't create a link for
every subsequent occurrence.
See also (slightly dated)
https://www.oracle.com/technical-resources/articles/java/javadoc-tool.html#inlinelinks
* Link to default to-number policies in ToNumberStrategy doc
* Reduce code duplication for deserializing Number
* Hide default factory constants of NumberTypeAdapter and ObjectTypeAdapter
This encapsulates the logic a little bit better.
Additionally refactored factory created by NumberTypeAdapter to only create
TypeAdapter once and then have factory reuse that adapter for better
performance.
Co-authored-by: Marcono1234 <Marcono1234@users.noreply.github.com>
When enum value was obfuscated by proguard, EnumTypeAdapter raise NoSuchFieldException even if apply SerializedName annotation.
Because EnumTypeAdapter cannot find obfuscated enum constant field with its name.
When a type variable is referenced multiple times it needs to resolve
to the same value. Previously, the second attempt would abort
resolution early in order to protect against infinite recursion.
On some versions of Android (probably on some variants of the popular Samsung S4 phone), an older version of Gson is suspected to be bundled in, and gets picked up from the system classpath.
For those versions, the applications that include the latest Gson fail unexpectedly. This debug print will help confirm this issue.
* Fixed https://github.com/google/gson/issues/1310
Also renamed VersionUtils to more readable abstraction JavaVersion
Added support for debian naming convention
Using min supported version (6) as the default if JDK version can't be figured out
* Moved JavaVersion to an internal package
