* Perform numeric conversion for primitive numeric type adapters
This should probably not be visible to the user unless they use the
non-typesafe `Gson.toJson(Object, Type)` where unrelated number types can
be used, or when malformed generic containers are used. For example a
`List<Byte>` containing a Float.
This change also has the advantage of avoiding `JsonWriter.value(Number)`
for primitive type adapters. That method has some overhead because it needs
to make sure that the value is a valid JSON number. However, for primitive
numbers this check is redundant.
* Don't call `JsonWriter.value(float)` for backward compatibility
* Fix typo in comments
The JsonSerializer/Deserializer adapters used to ignore this attribute
which result in inconsistent behaviour for annotated adapters.
Fixes#1553
Signed-off-by: Dmitry Bufistov <dmitry@midokura.com>
Co-authored-by: Dmitry Bufistov <dmitry@midokura.com>
* Gson.toJson creates CharSequence which does not implement toString
* Improve Streams.AppendableWriter.CurrentWrite test
* Make setChars package-private
* Improve AppendableWriter performance
Override methods which by default create char arrays or convert
CharSequences to Strings.
This is not necessary for AppendableWriter because it can directly
append these values to the Appendable delegate.
* Add test for Streams.writerForAppendable
* Make Object and JsonElement deserialization iterative
Often when Object and JsonElement are deserialized the format of the JSON
data is unknown and it might come from an untrusted source. To avoid a
StackOverflowError from maliciously crafted JSON, deserialize Object and
JsonElement iteratively instead of recursively.
Concept based on 51fd2faab7
But implementation is not based on it.
* Improve imports grouping
* Address review feedback
Follow-up to comments on #2130, which introduced a new override which was not overridden by `JsonTreeWriter`. Also tweaks the doccomments for `float`, `double` and `Number` variants of `JsonWriter.value`.
Supplement to the fix for #1127.
* Add comments regarding multiple bounds of wildcard
* Remove WildcardType check in getCollectionElementType
The returned Type is never a wildcard due to the changes made to getSupertype
by commit b1fb9ca9a1.
* Remove redundant getRawType call from MapTypeAdapterFactory
getRawType(TypeToken.getType()) is the same as calling TypeToken.getRawType().
* Make TypeToken members private
* Remove incorrect statement about TypeToken wildcards
It is possible to use wildcards as part of the type argument, e.g.:
`new TypeToken<List<? extends CharSequence>>() {}`
* Only allow direct subclasses of TypeToken
Previously subclasses of subclasses (...) of TypeToken were allowed which
can behave incorrectly when retrieving the type argument, e.g.:
class SubTypeToken<T> extends TypeToken<Integer> {}
new SubTypeToken<String>() {}.getType()
This returned `String` despite the class extending TypeToken<Integer>.
* Throw exception when TypeToken captures type variable
Due to type erasure the runtime type argument for a type variable is not
available. Therefore there is no point in capturing a type variable and it
might even give a false sense of type-safety.
* Make $Gson$Types members private
* Rename $Gson$Types.getGenericSupertype parameter
Rename the method parameter to match the documentation of the method and
to be similar to getSupertype(...).
* Improve tests and handle raw TypeToken supertype better
* Make some $Gson$Types members package-private again to prevent synthetic accessors
* Remove TypeToken check for type variable
As mentioned in review comments, there are cases during serialization where
usage of the type variable is not so problematic (but still not ideal).
* Add support for reflection access filter
* Improve documentation
* Fix compilation errors
* Relax handling for BLOCK_ALL when invoking default constructor
* Improve handling for inherited fields
* Fix accessible test failing for static fields
* Simplify ReflectiveTypeAdapterFactory field writing
* Fix GsonBuilder changes affecting created Gson instances
* Improve documentation
* Improve handling for IllegalAccessException
For Java < 9, AccessibleObject.canAccess is not available and therefore checks
might pass even if object is not accessible, causing IllegalAccessException
later.
* Fix incorrect GsonBuilder.addReflectionAccessFilter documentation
* Added parsing support for enum that has overridden toString() method.
* Fix a tiny formatting problem
* Fixed formatting issue
Co-authored-by: Éamonn McManus <emcmanus@google.com>
* Add CodeQL GitHub code scanning workflow
* Only compile main sources for code scanning
* Move test .proto files to test sources
`annotations.proto` also seems to be only relevant for tests because the test
explicitly registers them as extensions. By default the Proto adapter does not
consider them.
* Address some code scanning findings
* Fix some more findings
* 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
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.
* 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.
* 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
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.
* 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()
JsonAdapter is cached per the type of the JsonAdapter class.
Added a test to ensure JsonAdapter works on fields of parameterized types
Keep track of registered JsonAdapters and JsonAdapterFactorys in ThreadLocal.
The common cases (no @SerializedName and a single-value @SerializedName) now use a specialized one-element collection. Cases with alternate names use a much more space efficient ArrayList which is exactly sized.
This is also a performance win for adapter initialization since an index-based loop was used on the returned type for which LinkedList is not suited for.
When calling value() with a Boolean overload resolution would choose value(boolean) which would throw an NPE on null. The other boxed types are all numbers which would resolve to value(Number) and behave correctly.
