为何Gradle/ANT构建会因泛型类型转换失败？

这个问题的核心是Eclipse使用的ECJ编译器和Gradle/ANT依赖的javac（Oracle/Sun官方编译器）在泛型类型推断与参数匹配的实现上存在差异，具体原因拆解如下：

1. 两个编译器的类型检查逻辑不同 #

先看你的调用代码：

T result = q.<Person>getObject(person.getClass());

• Eclipse ECJ编译器：它对显式指定的泛型类型参数<Person>优先级更高，会直接将getObject的返回值绑定为Person类型，同时宽松处理person.getClass()的类型——虽然person.getClass()实际返回的是Class<? extends Person>（如果person是Person子类的实例，getClass返回子类的Class对象），ECJ会认为这个参数与Class<Person>兼容，因此编译通过。
• javac编译器：它的类型检查更严格。当你显式指定<Person>作为泛型参数时，getObject的参数要求是Class<Person>，但person.getClass()返回的是Class<? extends Person>，这两者并不严格匹配。此时javac会忽略你显式指定的<Person>，转而根据参数类型推断getObject的返回值为Object，自然就抛出了"required: T, found: Object"的类型不兼容错误。

2. 强制转换能解决问题的原因 #

两种强制转换写法本质上都是给javac一个明确的类型提示，绕过严格的类型检查：

• 写法1：q.<Person>getObject((Class<T>)person.getClass())
  这里把person.getClass()强转为Class<T>，让javac认为参数完全符合getObject的Class<T>要求，此时显式指定的<Person>类型参数会生效，返回值被推断为Person，与T兼容。
• 写法2：(T) q.<Person>getObject(person.getClass())
  这种是直接对返回值做类型断言，虽然会产生"unchecked cast"的警告，但javac会接受这个手动的类型承诺，允许赋值给T类型的变量。

3. 关于编译参数与严格检查 #

javac确实有一些参数可以增强泛型检查，比如-Xlint:unchecked会提示未检查的类型转换，但你的问题本质不是因为开启了严格检查，而是两个编译器的类型推断逻辑差异。不过如果你想让javac的行为更接近ECJ，并没有直接的参数可以做到——因为这是编译器实现层面的区别，而非配置项。

更优雅的解决方案 #

其实你可以避免这种编译器差异问题，直接传入明确的Class对象而非通过getClass()获取：

T result = q.getObject(Person.class);

这样无论用ECJ还是javac，类型推断都会准确无误，不需要任何强制转换。

内容的提问来源于stack exchange，提问作者vinodpthmn