Eclipse/javac 不同意使用默认方法冲突编译签名；谁是对的？

Question

这是一个演示问题的简单类：

package com.mimvista.debug;

public class DefaultCollisionTest {
    public static interface Interface1 {
        public String getName();
    }

    public static interface Interface2 {
        public default String getName() { return "Mr. 2"; };
    }

    public static <X extends Interface1&Interface2> String extractName(X target) {
        return target.getName();
    }
}

Eclipse (Neon 2) 愉快地编译这个类，而 javac (JDK 1.8.0_121) 吐出以下编译错误：

$ javac src/com/mimvista/debug/DefaultCollisionTest.java
src\com\mimvista\debug\DefaultCollisionTest.java:13: error: class INT#1 inherits abstract and default for getName() from types Interface2 and Interface1
        public static <X extends Interface1&Interface2> String extractName(X target) {
                       ^
  where INT#1 is an intersection type:
    INT#1 extends Object,Interface1,Interface2
1 error

我相信 Eclipse 在这种情况下是正确的，但我并不完全确定。根据我对“继承抽象和默认”错误的理解，我认为它应该只在编译实现这两个接口的实际声明类时生成。似乎 javac 可能在后台生成一个中间类来处理该通用签名并错误地对其进行默认方法冲突测试？

Answer 1

根据 JLS 9.4.1.3. Interfaces > Inheriting Methods with Override-Equivalent Signatures，Javac 是正确的：

如果接口I 继承了一个默认方法，其签名与I 继承的另一个方法等效，则会发生编译时错误。 （无论其他方法是抽象的还是默认的都是这种情况。）

小字解释：

[...] 当抽象和具有匹配签名的默认方法被继承时，我们会产生错误。在这种情况下，可以优先考虑其中之一——也许我们会假设默认方法也为抽象方法提供了合理的实现。但这是有风险的，因为除了巧合的名称和签名之外，我们没有理由相信默认方法的行为与抽象方法的约定一致——在最初开发子接口时，默认方法甚至可能不存在。在这种情况下，要求用户主动断言默认实现是适当的（通过覆盖声明）会更安全。

相比之下，类中继承的具体方法的长期行为是它们覆盖接口中声明的抽象方法（请参阅§8.4.8）。关于潜在合同违反的相同论点适用于此，但在这种情况下，类和接口之间存在固有的不平衡。为了保持类层次结构的独立性，我们更喜欢通过简单地优先考虑具体方法来最大限度地减少类接口冲突。

也与8.4.8.4. Classes > Inheriting Methods with Override-Equivalent Signatures比较：

如果一个类 C 继承了一个默认方法，其签名与另一个 C 继承的方法重写等效，则这是一个编译时错误，除非存在一个在 C 的超类中声明并由 C 继承的被重写的抽象方法- 等效于这两种方法。

当在超类中声明抽象方法时，会出现严格的默认抽象和默认默认冲突规则的例外情况：来自超类层次结构的抽象断言本质上胜过默认方法，从而使默认方法表现得好像它是抽象的。但是，类的抽象方法不会覆盖默认方法，因为仍然允许接口细化来自类层次结构的抽象方法的签名。

用更简单的话来说：假设这两个接口在逻辑上是不相关的，并且都指定了某种行为契约。因此，假设Interface2 中的默认实现是Interface1 合同的有效履行是不安全的。抛出错误，让开发者自己解决，这样比较安全。

我没有在 JLS 中找到可以完全解决您的情况的位置，但我认为错误在于上述规范的要点 - 您声明 extractName() 应该采取实现Interface1 和Interface2 的对象。但是对于这样的对象，只有当“存在一个在 C 的超类中声明并由 C 继承的抽象方法，该方法与这两个方法重写等效”时才有效。您的泛型声明没有指定任何关于 X 超类的内容，因此编译器将其视为“抽象默认”冲突。

Answer 2

Eclipse 是对的。

我没有在Java Bug Database 中发现这个javac 错误，因此报告了它：JDK-8186643

Stephan Herrmann 更好的解释（见his comment below）：

是的，仅当交集类型格式不正确且因此交集为空时，才应针对交集类型报告错误。但正如这个答案所示，交叉点不是空的，因此应该是合法的。实际上，错误消息class INT#1 inherits ... 没有任何意义，因为那时没有人提到 class INT#1，我们只有两个 interfaces 的交集，而那个交集仅用作绑定，不用作类型。

实现同一方法的多个接口的类可以用两种编译器编译，即使一个接口的方法具有默认实现。只要 I1 和 I2 都没有同名方法的默认实现，则该类可以引用为 <T extends I1 & I2>。仅当两个接口之一具有默认实现时 javac 失败。

如果有歧义应该应用哪个实现，错误应该在定义一个类时已经发生，而不是当该类被称为<T extends ...>（参见 JLS 4.9. Intersection Types）。

请参阅以下示例，该示例适用于 <T extends I1 & I2> 和 <T extends IDefault>，但适用于 <T extends I1 & IDefault> 和 javac：

interface I1 {
    String get();
}

interface I2 {
    String get();
}

interface IDefault {
    default String get() {
        return "default";
    };
}

public class Foo implements I1, I2, IDefault {

    @Override
    public String get() {
        return "foo";
    }

    public static void main(String[] args) {
        System.out.print(getOf(new Foo()));
    }

//  static <T extends I1 & IDefault> String getOf(T t) { // fails with javac
    static <T extends I1 & I2> String getOf(T t) { // OK
        return t.get();
    }

}

Answer 3

据我了解，问题是关于将已编译类的对象作为参数传递。由于您不能使用抽象类或接口调用 extractName(X) 方法，因此参数对象必须具有解析且明确的 getName() 方法。 Java 使用后期绑定来解析在运行时调用了哪个被覆盖的方法，所以我同意 BonusLord 的观点，即即使javac 抛出错误，该方法也可以正确编译和运行。

Answer 4

我会说这是一个 Javac 错误，或者至少应该是。

看起来 Javac 的实现者采取了捷径，在泛型边界的实现中重用了创建接口的代码。 IOW，Javac 对待 <X extends I1&I2> 好像是interface X extends I1, I2。

然而，实际上<X extends I1&I2> 是不同的。这只是意味着X 具有I1 和I2 的方法，但没有说明方法的实现。因此，default 实现是否存在应该是无关紧要的。

不幸的是，正如@slim 所说，目标是通过 JDK 的编译器，所以 Javac 说了算。提交错误报告，可以吗？