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!
Marcono1234