These show up with recent Error Prone analyses for Truth. Because the
tests use the overload of `Gson.fromJson` that takes a `Type` argument,
rather than the one with a `TypeToken`, the type mismatches were not
detected by the compiler.
* Port Junit assert to Truth in `com.google.gson.stream`
* Port Junit assert to Truth in `com.google.gson.regression`
* Port Junit assert to Truth in `om.google.gson.reflect`
* Port Junit assert to Truth in `com.google.gson.metrics`
* Port Junit assert to Truth in `com.google.gson.internal`
* Port Junit assert to Truth in `com.google.gson.internal.sql`
* Port Junit assert to Truth in `com.google.gson.internal.reflect`
* Port Junit assert to Truth in `com.google.gson.internal.bind`
* Port Junit assert to Truth in `com.google.gson.internal.bind.util`
* Port Junit assert to Truth in `com.google.gson.functional`
* Replaces `List.of` with `Arrays.asList` to grant legacy
* Simplify `==` asserts
* Simplify `.contain()` asserts + Minor fixes
* Simplify asserts
* Add Gson.fromJson(..., TypeToken) overloads
Previously only Gson.fromJson(..., Type) existed which is however not
type-safe since the generic type parameter T used for the return type is
not bound.
Since these methods are often used in the form
gson.fromJson(..., new TypeToken<...>(){}.getType())
this commit now adds overloads which accept a TypeToken and are therefore
more type-safe.
Additional changes:
- Fixed some grammar mistakes
- Added javadoc @see tags
- Consistently write "JSON" in uppercase
- More precise placement of @SuppressWarnings("unchecked")
* Add to Gson.fromJson javadoc that JSON is fully consumed
The newly added documentation deliberately does not state which exception
is thrown because Gson.assertFullConsumption could throw either a
JsonIOException or a JsonSyntaxException.
* Remove unnecessary wrapping and unwrapping as TypeToken in Gson.fromJson
Since the actual implementation of Gson.fromJson is TypeToken based, the
TypeToken variant overloads are now the "main" implementation and the other
overloads delegate to them.
Previously the Type variant overloads were the "main" implementation which
caused `TypeToken.getType()` followed by `TypeToken.get(...)` when the
TypeToken variant overloads were used.
* Trim source code whitespaces
* Fix Gson.fromJson(JsonReader, Class) not casting read Object
To be consistent with the other Gson.fromJson(..., Class) overloads the
method should cast the result.
* Replace User Guide link in Gson documentation
* Remove more references to fromJson(..., Type)
* Extend documentation for fromJson(JsonReader, ...)
* Replace some TypeToken.getType() usages
* Address feedback; improve documentation
* Remove fromJson(JsonReader, Class) again
As noticed during review adding this method is source incompatible.
This avoids needing to parse number if the equivalent object field doesn't exist.
It also avoids the performance penalty of trying to parse it eagerly as a big decimal, float etc.
This restructuring greatly cleans up the code and reduces some complexity; however, there is more that can be done to clean this up (i.e. get rid of "InstanceCreators" for primitive Type Adapters).
This helps is handling cases where the user is using their own subclass of Collection or Map.
Updated ParameterizedTypeHandlerMap to return the handler corresponding to Map and Collection for subclasses if user has not specified a specific handler.
Fixed the logic in JsonTreeNavigator to not output a comma if the first field of an object was null.
Éamonn McManus