* Formatting follow-up
- Adds formatting commits to .git-blame-ignore-revs so that they don't
distract during Git blame
- Restores hard line breaks in Troubleshooting.md using `\` instead of
trailing spaces
- Changes formatting of some string literals and comments
- Fixes accidental Javadoc and comment issues introduced by manual changes
of formatting commit
- Fixes license header in $Gson$Types.java erroneously being a Javadoc
comment and being reformatted
- Slightly changes `JsonReader` `getPath` and `getPreviousPath` documentation
to help Javadoc detect first sentence as summary
* Remove `spotless:off` markers
* Add empty line before comment
* Check format for .github YAML files
* Prevent `TypeToken` from capturing type variables
* Use hyphen for term "type-safe"
Not completely sure if that is grammatically correct, but it might make the
text a bit easier to understand.
* Update Troubleshooting Guide URLs in tests from 'master' to 'main'
* Rename system property
* Simplify system property check
This partially restores the behavior before a589ef2008,
except that back then for a non-generic type a bogus `TypeToken(ParameterizedType)`
was created, whereas now a `TypeToken(Class)` is created instead.
* Add code shrinking tools integration test
* Keep no-args constructor of classes usable with JsonAdapter
* Add library ProGuard rules for Gson
They are automatically applied for all users of Gson, see
https://developer.android.com/build/shrink-code#configuration-files
* Skip japicmp-maven-plugin for shrinker-test
* Add more tests for JsonAdapter, add tests for generic classes
* Extend default constructor test
* Add Troubleshooting Guide entry for TypeToken
* 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.
* 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).
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.
This removes a bunch of unnecessary public APIs and looks more like the GSON code that existed before this whole exercise. We no longer use TypeToken.isAssignable. I wrote a test that demonstrates at least one problem with that method, so I've deprecated it. We should be able to remove it release-after-next; nobody should be using this method anyway.
There are still some things that are public that shouldn't be. In particular there's some APIs in Types that are needed by TypeToken, which is unfortunately in a different package. Traditionally the fix is to create an 'internal' package and make the shared code public in the internal package. I'm not sure what we want to do for GSON; we could also use reflection (yuck) or duplicate the code (yuck).
The most significant impact of this change is that fields whose types are type parameters should now GSONify just fine. For example, consider the class below.
abstract class Foo<A, B> {
A a;
B b;
List<A> list;
Map<A, List<B>> map;
}
class RealFoo extends Foo<String, Integer> {...}
This is a reasonable checkpoint but some work still needs to be done for this. In particular, the level of visibility of methods in TypeToken and Type should be reconsidered; we're exposing more than we need to!
