为什么隐藏的静态方法在 Sun JDK 6 下可以编译，但在 OpenJDK 6 和 7 下会编译失败？

Question

以下类：

public class StaticMethodsDemo {

    public static class A {
        public static A make() { return new A(); };
    }
    public static class B extends A {
        public static B make() { return new B(); };
    }
    public static class BPrime<T> extends A {
        public static <T> BPrime<T> make() { return new BPrime<T>(); };
    }

    public static void main(String[] args) {
        B.make();
        // compiles under Sun JDK 1.6.0_20 but fails under Oracle JDK 1.7.0_01. Why?
        BPrime.<Object>make();
    }
}

在 Sun JDK 1.6.0_20（Windows 64 位，但应该没有区别）下编译，但在 Oracle JDK 1.7.0_01（同一平台）和 OpenJDK 1.6.0_20 (Ubuntu) [1] 下失败：

[ERROR] StaticMethodsDemo.java:[37,14] error: reference to make is ambiguous, both method make() in A and method <T>make() in BPrime match

为什么？通用参数（应该被删除，不是吗？）是如何导致这种明显的不匹配的。请注意，按如下方式删除泛型：

...
public static class BPrime<T> extends A {
    T val;
    public static BPrime<?> make() { return new BPrime<Object>(); };
    public void setT(T val) { this.val = val; }
}

public static void main(String[] args) {
    B.make();
    BPrime<Long> bprime = (BPrime<Long>) BPrime.make();
    bprime.setT(Long.valueOf(10));
}

也会编译并运行（因此泛型黑客不会导致任何奇怪的运行时转换错误）。

问题 461：使用普通 ubuntu openjdk 进行 jclouds-core 编译失败

Answer 1

显然，javac6 的行为是合理的，而 javac7 则不然。

不幸的是，根据规范的文字，javac7 是正确的。

这是由于java中的万恶之源——类型擦除。动机是在不破坏任何引用旧的、非泛化的集合 API 的旧代码的情况下泛化集合 API。为了简洁起见，我们将其称为“最愚蠢的动机”。

编译 BPrime.

然后我们需要知道类 B' 中的所有方法，包括继承的方法。这取决于 B' 中的方法 make() (mb) 是否隐藏方法 make() (< em>ma) 在 A 中；这取决于 mb 的签名是否是 ma 的子签名。 ( http://java.sun.com/ docs/books/jls/third_edition/html/classes.html#8.4.8）

子签名概念的存在也是为了服务于最愚蠢的动机。否则，我们只需要担心确定覆盖和隐藏方法时的相同签名。

但这次这不是问题。根据定义，mb 不是 ma 的子签名，因此 ma 在类 B' 中继承。因此类 B' 有两个 make() 方法。

下一步是确定潜在适用的方法。规则说（ http://java.sun .com/docs/books/jls/third_edition/html/expressions.html#15.12.2.1）

<块引用>

如果方法调用包含显式类型参数，并且该成员是泛型方法，则实际类型参数的数量等于形式类型参数的数量。

这意味着 ma 适用于表达式 BPrime.

规范解释了

上面的子句暗示非泛型方法可能适用于提供显式类型参数的调用。事实上，它可能会被证明是适用的。在这种情况下，类型参数将被忽略。

该规则源于兼容性问题和可替代性原则。由于接口或超类可以独立于其子类型进行泛型，因此我们可以用非泛型方法覆盖泛型方法。但是，重写（非泛型）方法必须适用于对泛型方法的调用，包括显式传递类型参数的调用。否则，子类型将无法替代其泛型超类型。

所以这也是为了服务于愚蠢的动机，我们必须允许像

    System.<String,Integer>currentTimeMillis();

Then这样的无意义语法，mb和ma都适用，因此歧义。