Explicitly specifying dependencies only seems to be necessary when using
`<proguardVersion>` config element to override version (and even that might
not be necessary; only adding explicit dependencies might suffice). However,
when omitting it, plugin uses a recent ProGuard version on its own.
* Remove UnsafeReflectionAccessor
Revert #1218
Usage of sun.misc.Unsafe to change internal AccessibleObject.override field
to suppress JPMS warnings goes against the intentions of the JPMS and does not
work anymore in newer versions, see #1540.
Therefore remove it and instead create a descriptive exception when making a
member accessible fails. If necessary users can also still use `java` command
line flags to open external modules.
* Fix failing to serialize Collection or Map with inaccessible constructor
Also remove tests which rely on Java implementation details.
* Don't keep reference to access exception of ConstructorConstructor
This also avoids a confusing stack trace, since the previously caught
exception might have had a complete unrelated stack trace.
* Remove Maven toolchain requirement
* Address review feedback
* Add back test for Security Manager
* Improve TreeTypeAdapter thread-safety
Gson claims to be thread-safe so TreeTypeAdapter.delegate() might be
called by multiple threads. To guarantee that each thread sees a fully
constructed `delegate`, the field has to be `volatile`.
* Improve TreeTypeAdapter thread race comment
* Improve Gson newJsonWriter and newJsonReader documentation
* Consider lenient and HTML-safe setting for Gson.newJsonWriter
* Remove empty line between imports
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>
* Fix RuntimeTypeAdapterFactory depending on internal Streams class
* Clean up gson-extras project, make it Maven module of gson-parent
* Remove broken test from GraphAdapterBuilderTest
