Lựa chọn chữ ký phương thức cho biểu thức lambda với nhiều loại mục tiêu phù hợp

Tôi đã trả lời một câu hỏi và chạy vào một kịch bản mà tôi không thể giải thích. Xem xét mã này:

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

Tôi không hiểu tại sao gõ một cách rõ ràng các paramter của lambda (A a) -> aList.add(a)làm cho mã được biên dịch. Ngoài ra, tại sao nó liên kết đến tình trạng quá tải Iterablethay vì một trong CustomIterable?
Có một số giải thích cho điều này hoặc một liên kết đến phần có liên quan của thông số kỹ thuật?

Lưu ý: iterable.forEach((A a) -> aList.add(a));chỉ biên dịch khi CustomIterable<T>mở rộng Iterable<T>(quá tải các phương thức trong CustomIterablekết quả trong lỗi không rõ ràng)

Nhận được điều này trên cả hai:

• phiên bản openjdk "13.0.2" 2020-01-14
  Trình biên dịch Eclipse
• phiên bản openjdk "1.8.0_232"
  Trình biên dịch Eclipse

Chỉnh sửa : Đoạn mã trên không thể biên dịch khi xây dựng bằng maven trong khi Eclipse biên dịch dòng mã cuối cùng thành công.

TL; DR, đây là một lỗi biên dịch.

Không có quy tắc nào được ưu tiên cho một phương thức áp dụng cụ thể khi nó được kế thừa hoặc một phương thức mặc định. Thật thú vị, khi tôi thay đổi mã thành

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
}

các iterable.forEach((A a) -> aList.add(a));tuyên bố tạo ra một lỗi trong Eclipse.

Vì không có thuộc tính của forEach(Consumer<? super T) c)phương thức từIterable<T> giao diện thay đổi khi khai báo một tình trạng quá tải khác, nên quyết định chọn phương thức này của Eclipse không thể (nhất quán) dựa trên bất kỳ thuộc tính nào của phương thức. Đây vẫn là phương thức được kế thừa duy nhất, vẫn là defaultphương thức duy nhất , vẫn là phương thức JDK duy nhất, v.v. Cả hai thuộc tính này sẽ không ảnh hưởng đến việc lựa chọn phương thức nào.

Lưu ý rằng thay đổi khai báo thành

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

cũng tạo ra một lỗi mập mờ mơ hồ, do đó, số lượng phương thức quá tải có thể áp dụng cũng không thành vấn đề, ngay cả khi chỉ có hai ứng cử viên, không có ưu tiên chung nào đối với default các phương thức.

Cho đến nay, vấn đề dường như xuất hiện khi có hai phương pháp áp dụng và default phương pháp và mối quan hệ thừa kế có liên quan, nhưng đây không phải là nơi thích hợp để đào sâu hơn.

Nhưng có thể hiểu rằng các cấu trúc của ví dụ của bạn có thể được xử lý bằng các mã triển khai khác nhau trong trình biên dịch, một cấu trúc thể hiện một lỗi trong khi cái kia thì không.
a -> aList.add(a)là một biểu thức lambda được gõ ngầm , không thể được sử dụng cho độ phân giải quá tải. Ngược lại, (A a) -> aList.add(a)là một biểu thức lambda được gõ rõ ràng có thể được sử dụng để chọn một phương thức khớp từ các phương thức bị quá tải, nhưng nó không giúp ích ở đây (không nên trợ giúp ở đây), vì tất cả các phương thức đều có các loại tham số có cùng chữ ký chức năng .

Như một ví dụ ngược lại, với

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

các chữ ký chức năng khác nhau và sử dụng biểu thức lambda loại rõ ràng thực sự có thể giúp chọn đúng phương thức trong khi biểu thức lambda được gõ ngầm không giúp ích gì, vì vậy forEach(s -> s.isEmpty()) tạo ra lỗi trình biên dịch. Và tất cả các trình biên dịch Java đều đồng ý về điều đó.

Lưu ý rằng đó aList::addlà một tham chiếu phương thức mơ hồ, vì addphương thức cũng bị quá tải, do đó, nó cũng không thể giúp chọn một phương thức, nhưng dù sao các tham chiếu phương thức có thể được xử lý bởi các mã khác nhau. Chuyển sang một cách rõ ràng aList::containshoặc thay đổi Listthành Collection, để addrõ ràng, không thay đổi kết quả trong cài đặt Eclipse của tôi (tôi đã sử dụng 2019-06).

Trình biên dịch Eclipse giải quyết chính xác defaultphương thức , vì đây là phương thức cụ thể nhất theo Đặc tả ngôn ngữ Java 15.12.2.5 :

Nếu chính xác một trong những phương thức cụ thể tối đa là cụ thể (nghĩa là không abstracthoặc mặc định), thì đó là phương pháp cụ thể nhất.

javac(được sử dụng bởi Maven và IntelliJ theo mặc định) cho biết cuộc gọi phương thức không rõ ràng ở đây. Nhưng theo Đặc tả ngôn ngữ Java thì không mơ hồ vì một trong hai phương thức là phương thức cụ thể nhất ở đây.

Các biểu thức lambda được gõ ngầm được xử lý khác với các biểu thức lambda được gõ rõ ràng trong Java. Được gõ hoàn toàn trái ngược với các biểu thức lambda được gõ rõ ràng rơi vào giai đoạn đầu tiên để xác định các phương thức gọi nghiêm ngặt (xem Đặc tả ngôn ngữ Java jls-15.12.2.2 , điểm đầu tiên). Do đó, cách gọi phương thức ở đây không rõ ràng đối với các biểu thức lambda được gõ ngầm .

Trong trường hợp của bạn, cách giải quyết cho javaclỗi này là chỉ định loại giao diện chức năng thay vì sử dụng biểu thức lambda được gõ rõ ràng như sau:

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

hoặc là

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

Dưới đây là ví dụ của bạn được giảm thiểu để thử nghiệm:

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

}

Mã nơi Eclipse triển khai JLS §15.12.2.5 không tìm thấy phương thức nào cụ thể hơn phương thức kia, ngay cả đối với trường hợp lambda được gõ rõ ràng.

Vì vậy, lý tưởng Eclipse sẽ dừng lại ở đây và báo cáo sự mơ hồ. Thật không may, việc thực hiện giải quyết quá tải có mã không tầm thường ngoài việc thực hiện JLS. Theo hiểu biết của tôi, mã này (bắt đầu từ thời điểm Java 5 mới) phải được giữ lại để điền vào một số khoảng trống trong JLS.

Tôi đã nộp https://bugs.eclipse.org/562538 để theo dõi điều này.

Không phụ thuộc vào lỗi đặc biệt này, tôi chỉ có thể khuyên mạnh mẽ chống lại kiểu mã này. Quá tải là tốt cho một số lượng lớn các bất ngờ trong Java, được nhân với suy luận kiểu lambda, độ phức tạp khá vượt trội so với mức tăng nhận thức được.