Metode pemilihan tanda tangan untuk ekspresi lambda dengan beberapa tipe target yang cocok

Saya menjawab pertanyaan dan mengalami skenario yang tidak bisa saya jelaskan. Pertimbangkan kode ini:

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

Saya tidak mengerti mengapa secara eksplisit mengetik paramter dari lambda (A a) -> aList.add(a)membuat kode dikompilasi. Selain itu, mengapa tautan ke kelebihan di dalam Iterabledaripada di CustomIterable?
Apakah ada penjelasan untuk ini atau tautan ke bagian spesifikasi yang relevan?

Catatan: iterable.forEach((A a) -> aList.add(a));hanya mengkompilasi ketika CustomIterable<T>diperluas Iterable<T>(secara berlebihan membebani metode dalam CustomIterablehasil dalam kesalahan ambigu)

Mendapatkan ini pada keduanya:

• versi openjdk "13.0.2" 2020-01-14
  Compiler Eclipse
• versi openjdk "1.8.0_232"
  Kompilator Eclipse

Sunting : Kode di atas gagal dikompilasi pada bangunan dengan pakar sementara Eclipse berhasil mengkompilasi baris kode terakhir.

TL; DR, ini adalah bug penyusun.

Tidak ada aturan yang akan diutamakan untuk metode tertentu yang berlaku ketika diwariskan atau metode default. Menariknya, ketika saya mengubah kode ke

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
}

yang iterable.forEach((A a) -> aList.add(a));pernyataan menghasilkan kesalahan dalam Eclipse.

Karena tidak ada properti forEach(Consumer<? super T) c)metode dari Iterable<T>antarmuka berubah ketika menyatakan kelebihan lainnya, keputusan Eclipse untuk memilih metode ini tidak dapat (secara konsisten) didasarkan pada properti metode apa pun. Itu masih satu-satunya metode yang diwariskan, masih satu-satunya defaultmetode, masih satu-satunya metode JDK, dan seterusnya. Tak satu pun dari properti ini yang akan memengaruhi pemilihan metode.

Perhatikan bahwa mengubah deklarasi menjadi

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

juga menghasilkan kesalahan "ambigu", sehingga jumlah metode kelebihan beban yang berlaku juga tidak masalah, bahkan ketika hanya ada dua kandidat, tidak ada preferensi umum terhadap defaultmetode.

Sejauh ini, masalah tampaknya muncul ketika ada dua metode yang berlaku dan defaultmetode dan hubungan warisan yang terlibat, tetapi ini bukan tempat yang tepat untuk menggali lebih jauh.

Tetapi dapat dimengerti bahwa konstruk dari contoh Anda dapat ditangani oleh kode implementasi yang berbeda di kompiler, yang satu menunjukkan bug sementara yang lain tidak.
a -> aList.add(a)adalah ekspresi lambda yang diketik secara implisit , yang tidak dapat digunakan untuk resolusi kelebihan beban. Sebaliknya, (A a) -> aList.add(a)adalah ekspresi lambda yang diketik secara eksplisit yang dapat digunakan untuk memilih metode yang cocok dari metode kelebihan beban, tetapi itu tidak membantu di sini (seharusnya tidak membantu di sini), karena semua metode memiliki tipe parameter dengan tanda tangan fungsional yang persis sama .

Sebagai contoh tandingan, dengan

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

tanda tangan fungsional berbeda, dan menggunakan ekspresi lambda tipe eksplisit memang dapat membantu memilih metode yang tepat sedangkan ekspresi lambda yang diketik secara implisit tidak membantu, sehingga forEach(s -> s.isEmpty())menghasilkan kesalahan kompilator. Dan semua kompiler Java setuju tentang itu.

Perhatikan bahwa aList::addini adalah referensi metode yang ambigu, karena addmetode ini kelebihan beban juga, jadi itu juga tidak dapat membantu memilih metode, tetapi referensi metode mungkin akan diproses oleh kode yang berbeda pula. Beralih ke yang ambigu aList::containsatau berubah Listmenjadi Collection, untuk membuat addtidak ambigu, tidak mengubah hasil di instalasi Eclipse saya (saya menggunakan 2019-06).

Kompilator Eclipse dengan benar menyelesaikan ke defaultmetode , karena ini adalah metode yang paling spesifik sesuai dengan Spesifikasi Bahasa Jawa 15.12.2.5 :

Jika tepat salah satu metode spesifik maksimal adalah konkret (yaitu, non- abstractatau default), itu adalah metode yang paling spesifik.

javac(digunakan oleh Maven dan IntelliJ secara default) memberi tahu pemanggilan metode bersifat ambigu di sini. Tetapi menurut Spesifikasi Bahasa Jawa itu tidak ambigu karena salah satu dari dua metode adalah metode yang paling spesifik di sini.

Ekspresi lambda yang diketik secara implisit ditangani secara berbeda dari ekspresi lambda yang diketik secara eksplisit di Jawa. Secara implisit diketik berbeda dengan ekspresi lambda yang diketik secara eksplisit, jatuh pada fase pertama untuk mengidentifikasi metode doa yang ketat (lihat Spesifikasi Bahasa Jawa jls-15.12.2.2 , poin pertama). Oleh karena itu, pemanggilan metode di sini bersifat ambigu untuk ekspresi lambda yang diketik secara implisit .

Dalam kasus Anda, solusi untuk javacbug ini adalah menentukan jenis antarmuka fungsional alih-alih menggunakan ekspresi lambda yang diketik secara eksplisit sebagai berikut:

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

atau

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

Berikut adalah contoh Anda yang diperkecil lebih lanjut untuk pengujian:

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

}

Kode di mana Eclipse mengimplementasikan JLS §15.12.2.5 tidak menemukan metode mana pun lebih spesifik daripada yang lain, bahkan untuk kasus lambda yang diketik secara eksplisit.

Jadi idealnya Eclipse akan berhenti di sini dan melaporkan ambiguitas. Sayangnya, implementasi resolusi kelebihan memiliki kode non-sepele selain menerapkan JLS. Dari pemahaman saya kode ini (yang berasal dari saat Java 5 baru) harus disimpan untuk mengisi beberapa celah di JLS.

Saya telah mengajukan https://bugs.eclipse.org/562538 untuk melacak ini.

Terlepas dari bug khusus ini, saya hanya bisa sangat menyarankan terhadap gaya kode ini. Overloading baik untuk sejumlah kejutan di Jawa, dikalikan dengan inferensi tipe lambda, kompleksitas cukup di luar proporsi sesuai dengan perolehan yang dirasakan.