编译器对于泛型方法的空参数的行为有所不同

Question

下面的代码用Eclipse可以完美编译，但用javac编译失败：

public class HowBizarre {
      public static <P extends Number, T extends P> void doIt(P value) {
      }

      public static void main(String[] args) {
            doIt(null);
      }
}

我简化了代码，所以现在根本不用T了。尽管如此，我还是没有看到该错误的原因。 由于某种原因 javac 认为 T 代表 Object，然后抱怨 Object 不符合 T 的边界（这是真的）：

HowBizarre.java:6：不兼容的类型；推断类型参数 java.lang.Number、java.lang.Object 不符合类型边界 变量 P,T

发现：无效

必填：无效

 doIt(null);
           ^

请注意，如果我用非空值替换空参数，它可以正常编译。

哪个编译器的行为正确，为什么？这是其中之一的错误吗？

Answer 1

该问题是由于 JLS 规范要求必须将其他不可推断的类型参数推断为 Object，即使它不满足边界（并因此触发编译错误）。

以下是“bug”报告的摘录（为了清晰起见，已对其进行了进一步注释）：

“Bug”ID 6299211 - 方法类型变量：推断因 null 而中断

该程序无法编译：

公共类尝试{

    void m() {
        java.util.Collections.max(null);
    }
}

状态：已关闭，不是缺陷。

评估：这不是错误。推理算法无法从参数 (null) 收集任何信息，并且不会在对返回值有任何期望的地方调用该方法。在这种情况下，编译器必须推断出类型变量的java.lang.Object。

<小时>

JLS 15.12.2.8 推断未解析的类型参数

任何尚未推断的剩余类型变量都会被推断为 Object 类型

<小时>

但是，Object 不是 Comparable< 的子类型？ super Object>，因此不在 Collections.max 声明中类型变量的范围内：

对象 &可比> T max(集合)




---

进一步探索

使用显式类型参数“修复”问题：

HowBizarre.<Number,Integer>doIt(null); // compiles fine in javac

表明这与 null 参数关系不大，并且更多与绝对缺乏类型推断信息有关，您可以尝试以下任一声明：

<T,U extends Comparable<T>> void doIt()

<T extends Number,U extends T> void doIt()

在任何一种情况下，调用 doIt(); 都不会在 javac< 中编译/code>，因为它必须根据 15.12.2.8 推断 U 为 Object，即使这样做会触发编译错误。

---

关于 Eclipse 的注意事项

虽然上面的代码片段都不能在某些版本的 javac 中编译，但它们都可以在某些版本的 Eclipse 中编译。这表明 Eclipse 方面存在错误。众所周知，不同的编译器之间存在分歧。

相关问题

• 泛型在 Eclipse 中编译并运行，但是无法在 javac 中编译

Answer 2

这是javac 中的一个错误。 Eclipse推断正确的类型。

你可以通过调用 doIt((Number) null); 来

解决这个问题。即使你不打算使用 javac 进行开发，也可以解决这个问题，因为像 ant 或 maven 这样的工具会使用它，并且它会如果您在某个时候引入它们，则会出现问题。

Answer 3

根据 Polygenelubricants 的研究，sun 的 javac 显然符合规范。过去我也使用过其他编译器，当出现冲突时，结果总是sun的javac是正确的。 Sun 的优势在于将他们从实施过程中获得的经验记录到规范中，而其他人则必须从头开始阅读规范 - 当您阅读它时，真的很难不入睡。