There are situations where the stack of JsonTreeReader contains a JsonArray
or JsonObject without a subsequent Iterator, for example after calling peek()
or nextName().
When JsonTreeReader.getPath() is called afterwards it therefore must not
assume that a JsonArray or JsonObject is always followed by an Iterator.
The only reason why this never caused an ArrayIndexOutOfBoundsException in
the past is because the stack has an even default size (32) so it would just
have read the next `null`.
However, if the stack had for example the default size 31, a user created a
JsonTreeReader for 16 JSON arrays nested inside each other, then called 15
times beginArray(), followed by peek() and getPath() the exception would
occur.
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
* optimized the create() method, excludeClass used to get called two times, changed it to one
* fixed the create() method, and added support to disableAnonymousAndLocalClassSerialization
* peek only once
* enable anonymous and local class serialization
* bugfix
* removed the method, will raise it as a separate PR
* Added test which shows that lenient JsonWriter fails writing infinite primitive doubles, but does not fail writing boxed doubles, as stated in #1090.
* Fixed JsonWriter#value(double) to write infinite and NaN values when lenient, as JsonWriter#value(Number) does. (fixes#1090)
Now the thrown exception carries this information:
java.lang.IllegalArgumentException: Invalid attempt to bind an instance of java.lang.Integer as a @JsonAdapter for com.google.gson.functional.JsonAdapterAnnotationOnClassesTest$D. @JsonAdapter value must be a TypeAdapter, TypeAdapterFactory, JsonSerializer or JsonDeserializer.
* Simplified access of getSimpleName
instead of calling getClass.getSimpleName() that will check too many conditions inside , we can make it as final String and use it directly.
* Simplified access of getSimpleName
making string as static
* Simplified access of getSimpleName
Code Review changes
* calculating size of the list once in case of loops, avoided creation of string builder object if the length type argument is 0
* replaced null check boilerplate code with nullSafe()
These are useful when creating TypeAdapterFactories that delegate to others with more complex types. They also are useful when writing dynamic code that deals with types that cannot be fully reified using the normal subclass technique.