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

我正在回答一个问题，遇到了无法解释的情况。考虑以下代码：

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)会使代码编译。另外，为什么它链接到in中的超载Iterable而不是in中的一个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成功编译了最后一行代码。

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中产生错误。

由于声明另一个重载时接口的forEach(Consumer<? super T) c)方法属性没有Iterable<T>改变，因此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）。

Eclipse编译器正确地解析了该default方法，因为根据Java语言规范15.12.2.5，这是最具体的方法：

如果确切地说是最大的特定方法中的一种是具体的（即非abstract或默认），则它是最特定的方法。

javac（默认情况下由Maven和IntelliJ使用）告诉此方法调用是不明确的。但是根据Java语言规范，它并不是模棱两可的，因为这两种方法之一是这里最具体的方法。

隐式类型的 lambda表达式的处理方式与Java中的显式类型的lambda表达式不同。与显式类型的lambda表达式相反，隐式类型属于第一阶段，以标识严格调用的方法（请参阅Java语言规范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)
    }

}

Eclipse实现JLS§15.12.2.5的代码没有找到任何一个方法比另一个方法更具体，即使对于显式键入的lambda也是如此。

因此，理想情况下，Eclipse将在此处停止并报告歧义。不幸的是，重载解决方案的实现除了实现JLS之外，还具有不平凡的代码。根据我的理解，必须保留此代码（从Java 5发行之日起），以填补JLS中的某些空白。

我已提交https://bugs.eclipse.org/562538进行跟踪。

独立于此特定的错误，我只能强烈建议不要使用这种代码风格。在Java中，重载可以带来很多惊喜，再加上lambda类型推断，那么复杂度与感知到的收益就成比例了。