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.
* #1981: Avoid OSGi bundle's dependency on sun.misc package
* Specify optional dependency on sun.misc.Unsafe
* Adjusting the test to sun.misc import being optional
* Using Collections.list and for loop
* Let the fail message include name of package
Co-authored-by: Marcono1234 <Marcono1234@users.noreply.github.com>
* Closing the input stream
* Dedicated assertSubstring method
Co-authored-by: Marcono1234 <Marcono1234@users.noreply.github.com>
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.
Previously ISO8601UtilsTest.testDateFormatString() would fail on systems
where the time zone is UTC+X because getTime() returned "2018-06-24" for them.
Additionally the tests which previously changed the system locale and time
zone have been rewritten to create a UTC calendar instead. Setting locale
seems to not be necessary because ISO8601Utils.parse(...) does not do that
either.
