Guice的TypeLiteral是如何工作的?
Guice的TypeLiteral如何克服Java泛型类型擦除过程?
它的工作原理是奇迹,但这是如何实现的?
Guice的TypeLiteral如何克服Java泛型类型擦除过程?
它的工作原理是奇迹,但这是如何实现的?
这里使用的技巧是泛型超类型的签名存储在子类中,因此可以持久擦除。
如果你创建了一个匿名子类 Guice,可以在它上面调用 getClass().getGenericSuperclass(),
并获取一个 java.lang.reflect.ParameterizedType
,其中存在一个 getActualTypeArguments() 方法 getActualTypeArguments()
作为 .new TypeLiteral<List<String>>() {}
List<String>
ParameterizedType
通过匿名类型,子类化以及Java不会完全擦除所有泛型声明的事实的组合。
如果你仔细观察,TypeLiteral有一个受保护的构造函数,所以你在构造一个新的构造函数时使用一个额外的{},它创建了一个匿名的TypeLiteral子类。
在Java中,泛型声明保留在类和方法声明上,所以如果我写这个。
public abstract class Class1<T>
{
}
public class Class2 extends Class1<Integer>
{
}
我实际上可以在Class1中编写代码,如果Class2是子类,它可以弄清楚它自己的泛型类型是Integer。
查看java.lang.Class API以获取适当的方法(它们在名称中具有Generic)。