具有多个匹配目标类型的 lambda 表达式的方法签名选择

Question

我在回答 a question 时遇到了我无法解释的情况。考虑这段代码：

interface ConsumerOne<T> {
    void accept(T a);
}

interface CustomIterable<T> extends Iterable<T> {
    void forEach(ConsumerOne<? super T> c); //overload
}

class A {
    private static CustomIterable<A> iterable;
    private static List<A> aList;

    public static void main(String[] args) {
        iterable.forEach(a -> aList.add(a));     //ambiguous
        iterable.forEach(aList::add);            //ambiguous

        iterable.forEach((A a) -> aList.add(a)); //OK
    }
}

我不明白为什么显式输入 lambda (A a) -> aList.add(a) 的参数会使代码编译。此外，为什么它链接到Iterable 中的过载而不是CustomIterable 中的过载？
是否有对此的解释或规范相关部分的链接？

注意：iterable.forEach((A a) -> aList.add(a)); 仅在 CustomIterable<T> 扩展 Iterable<T> 时编译（直接重载 CustomIterable 中的方法会导致模棱两可的错误）

---

两者都得到这个：

• openjdk版本“13.0.2” 2020-01-14
  Eclipse 编译器
• openjdk 版本“1.8.0_232”
  Eclipse 编译器

编辑：上面的代码在用maven编译时编译失败，而Eclipse编译最后一行代码成功。

Answer 1

TL;DR，这是一个编译器错误。

没有规则会在继承或默认方法时优先使用特定的适用方法。有趣的是，当我将代码更改为

interface ConsumerOne<T> {
    void accept(T a);
}
interface ConsumerTwo<T> {
  void accept(T a);
}

interface CustomIterable<T> extends Iterable<T> {
    void forEach(ConsumerOne<? super T> c); //overload
    void forEach(ConsumerTwo<? super T> c); //another overload
}

iterable.forEach((A a) -> aList.add(a)); 语句在 Eclipse 中产生错误。

由于在声明另一个重载时没有更改来自Iterable<T> 接口的forEach(Consumer<? super T) c) 方法的属性，因此Eclipse 选择此方法的决定不能（始终）基于该方法的任何属性。它仍然是唯一继承的方法，仍然是唯一的 default 方法，仍然是唯一的 JDK 方法，依此类推。无论如何，这些属性都不应该影响方法选择。

请注意，将声明更改为

interface CustomIterable<T> {
    void forEach(ConsumerOne<? super T> c);
    default void forEach(ConsumerTwo<? super T> c) {}
}

也会产生“模糊”错误，因此适用的重载方法的数量也无关紧要，即使只有两个候选方法，也没有普遍偏好 default 方法。

到目前为止，当有两个适用的方法和一个default 方法和一个继承关系时，问题似乎出现了，但这不是进一步挖掘的正确地方。

---

但可以理解的是，您的示例的构造可能由编译器中的不同实现代码处理，一个显示错误而另一个没有。
a -> aList.add(a) 是一个隐式类型 lambda 表达式，不能用于重载决议。相比之下，(A a) -> aList.add(a) 是一个 显式类型 lambda 表达式，可用于从重载方法中选择匹配方法，但在这里没有帮助（在这里应该没有帮助），因为所有方法的参数类型具有完全相同的功能签名。

作为一个反例，与

static void forEach(Consumer<String> c) {}
static void forEach(Predicate<String> c) {}
{
  forEach(s -> s.isEmpty());
  forEach((String s) -> s.isEmpty());
}

函数签名不同，使用显式类型的 lambda 表达式确实可以帮助选择正确的方法，而隐式类型的 lambda 表达式没有帮助，因此forEach(s -> s.isEmpty()) 会产生编译器错误。并且所有 Java 编译器都同意这一点。

注意aList::add是一个模糊的方法引用，因为add方法也被重载了，所以它也不能帮助选择一个方法，但是方法引用可能会被不同的代码处理。切换到明确的aList::contains 或将List 更改为Collection，以使add 明确，并没有改变我的Eclipse 安装中的结果（我使用了2019-06）。

Answer 2

Eclipse 实现 JLS §15.12.2.5 的代码没有发现任何一种方法比另一种更具体，即使对于显式类型化的 lambda 也是如此。

所以理想情况下 Eclipse 会在此停止并报告歧义。不幸的是，除了实现 JLS 之外，重载解析的实现还有不平凡的代码。据我了解，必须保留这段代码（可以追溯到 Java 5 的新版本）以填补 JLS 中的一些空白。

我已提交 https://bugs.eclipse.org/562538 以跟踪此问题。

独立于这个特定的错误，我只能强烈建议不要使用这种代码风格。重载对 Java 中的许多惊喜都有好处，再加上 lambda 类型推断，复杂性与感知收益完全不成比例。

Answer 3

Eclipse 编译器正确解析为default 方法，因为根据Java Language Specification 15.12.2.5，这是最具体的方法：

如果最具体的方法之一是具体的（即， 非abstract或默认），这是最具体的方法。

javac（由 Maven 和 IntelliJ 默认使用）告诉方法调用在这里是不明确的。但根据 Java 语言规范，这并没有歧义，因为这两种方法之一是这里最具体的方法。

隐式类型 lambda 表达式的处理与 Java 中显式类型的 lambda 表达式不同。与显式类型的 lambda 表达式相比，隐式类型的 lambda 表达式属于识别严格调用方法的第一阶段（参见Java Language Specification jls-15.12.2.2，第一点）。因此，这里的方法调用对于隐式类型 lambda 表达式是不明确的。

在您的情况下，此javac 错误的解决方法 是指定功能接口的类型，而不是使用显式类型的 lambda 表达式，如下所示：

iterable.forEach((ConsumerOne<A>) aList::add);

或

iterable.forEach((Consumer<A>) aList::add);

这是您的示例进一步最小化以进行测试：

class A {

    interface FunctionA { void f(A a); }
    interface FunctionB { void f(A a); }

    interface FooA {
        default void foo(FunctionA functionA) {}
    }

    interface FooAB extends FooA {
        void foo(FunctionB functionB);
    }

    public static void main(String[] args) {
        FooAB foo = new FooAB() {
            @Override public void foo(FunctionA functionA) {
                System.out.println("FooA::foo");
            }
            @Override public void foo(FunctionB functionB) {
                System.out.println("FooAB::foo");
            }
        };
        java.util.List<A> list = new java.util.ArrayList<A>();

        foo.foo(a -> list.add(a));      // ambiguous
        foo.foo(list::add);             // ambiguous

        foo.foo((A a) -> list.add(a));  // not ambiguous (since FooA::foo is default; javac bug)
    }

}