การเลือกลายเซ็นของเมธอดสำหรับแลมบ์ดานิพจน์ที่มีเป้าหมายหลายประเภท

ฉันตอบคำถามและพบเจอสถานการณ์ที่ไม่สามารถอธิบายได้ พิจารณารหัสนี้:

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

แก้ไข : โค้ดด้านบนไม่สามารถคอมไพล์ในการสร้างด้วย 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)เป็นนิพจน์แลมบ์ดาที่พิมพ์โดยปริยายซึ่งไม่สามารถใช้สำหรับการแก้ปัญหาการโอเวอร์โหลด ในทางตรงกันข้าม(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)

คอมไพเลอร์ Eclipse แก้ไขdefaultวิธีได้อย่างถูกต้องเนื่องจากเป็นวิธีที่เฉพาะเจาะจงที่สุดตามข้อกำหนดภาษา Java 15.12.2.5 :

หากหนึ่งในวิธีที่เฉพาะเจาะจงที่สุดคือคอนกรีต (นั่นคือไม่ใช่abstractหรือค่าเริ่มต้น) มันเป็นวิธีที่เฉพาะเจาะจงมากที่สุด

javac(ใช้โดย Maven และ IntelliJ โดยค่าเริ่มต้น) บอกว่าการเรียกเมธอดนั้นไม่ชัดเจนที่นี่ แต่ตามข้อกำหนดภาษา Java มันไม่ชัดเจนเนื่องจากหนึ่งในสองวิธีนี้เป็นวิธีที่เฉพาะเจาะจงที่สุดที่นี่

การแสดงออกแลมบ์ดาที่พิมพ์โดยนัยโดยนัยได้รับการจัดการแตกต่างจากการแสดงออกแลมบ์ดาที่พิมพ์โดยชัดเจนใน Java ตรงกันข้ามกับการแสดงออกแลมบ์ดาที่พิมพ์โดยชัดแจ้งโดยปริยายในช่วงแรกเพื่อระบุวิธีการอุทธรณ์อย่างเข้มงวด (ดูJava Language Specification 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, คูณด้วยการอนุมานแลมบ์ดาชนิด, ความซับซ้อนค่อนข้างเกินสัดส่วนที่ได้รับ