複数の一致するターゲットタイプを持つラムダ式のメソッドシグネチャの選択

質問に答えていて、説明できないシナリオに出くわしました。このコードを考えてみましょう：

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
    }
}

ラムダのパラメーターを明示的に入力(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コンパイラ

編集：上記のコードは、Eclipseがコードの最後の行を正常にコンパイルしている間、mavenでビルドするとコンパイルに失敗します。

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) {}
}

また、「あいまいな」エラーが生成されるため、適用可能なオーバーロードされたメソッドの数も関係ありません。候補が2つしかない場合でも、defaultメソッドに対する一般的な優先順位はありません。

これまでのところ、2つの適用可能なメソッドがあり、defaultメソッドと継承関係が関係しているときに問題が発生するようですが、これはさらに掘り下げるには適切な場所ではありません。

しかし、例の構成要素がコンパイラの異なる実装コードによって処理される可能性があることは理解できます。1つはバグを示し、もう1つはバグを示しません。
a -> aList.add(a)ある暗黙に型付けされたオーバーロードの解決のために使用することはできませんラムダ式は、。これとは対照的に、(A a) -> aList.add(a)ある明示的に型指定されたオーバーロードされたメソッドからのマッチング方法を選択するために使用することができますラムダ式が、それはここで助けにはならない（はずここではないヘルプ）、すべてのメソッドはまったく同じ機能シグネチャとパラメータ型を持っているように。

反例として、

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

関数シグネチャは異なり、明示的に型指定されたラムダ式を使用すると正しい方法を選択するのに役立ちますが、暗黙的に型指定されたラムダ式は役に立たないため、forEach(s -> s.isEmpty())コンパイラエラーが発生します。そして、すべてのJavaコンパイラはこれについて同意します。

メソッドは多重定義さaList::addれているため、あいまいなメソッド参照であることに注意してください。メソッドのadd選択にも役立ちませんが、メソッド参照はとにかく別のコードで処理される可能性があります。明確に切り替えるか、明確にaList::containsするListためCollectionににadd変更しても、Eclipseインストールの結果は変わりませんでした（私はを使用しました2019-06）。

Java言語仕様15.12.2.5によると、これは最も具体的なメソッドであるため、default Eclipseコンパイラーは正しくメソッドを解決します。

abstract最も具体的な方法の1つが具体的（つまり、非デフォルト）である場合、それが最も具体的な方法です。

javac（デフォルトでMavenとIntelliJによって使用されます）メソッド呼び出しがここではあいまいであることを示します。しかし、Java言語仕様によると、2つのメソッドの1つがここで最も具体的なメソッドであるため、あいまいではありません。

暗黙的に型指定されたラムダ式は、Javaで明示的に型指定されたラムダ式とは異なる方法で処理されます。明示的に型指定されたラムダ式とは対照的に、暗黙的に型指定されたものは、厳密な呼び出しのメソッドを識別するために、最初のフェーズを通過します（Java言語仕様jls-15.12.2.2の最初のポイントを参照）。したがって、ここでのメソッド呼び出しは、暗黙的に型指定されたラムダ式ではあいまいです。

あなたの場合、このバグの回避策は、次のように明示的に型指定されたラムダ式を使用する代わりに、機能インターフェイスの型javacを指定することです。

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を実装するコードでは、明示的に型指定されたラムダの場合でも、どちらの方法も他よりも具体的であるとは見なされません。

したがって、理想的には、Eclipseはここで停止し、あいまいさを報告します。残念ながら、オーバーロード解決の実装には、JLSの実装に加えて重要なコードがあります。私の理解では、このコード（Java 5が新しくなったときからのもの）は、JLSのいくつかのギャップを埋めるために保持する必要があります。

これを追跡するために、https：//bugs.eclipse.org/562538を提出しました。

この特定のバグとは関係なく、私はこのスタイルのコードに対してのみ強くアドバイスすることができます。オーバーロードは、ラムダ型の推論を乗じた、Javaでの多くの驚きに適しています。複雑さは、知覚される利得とは比例していません。