일치하는 여러 대상 유형이있는 람다 식에 대한 메서드 서명 선택

나는 질문 에 대답 하고 있었다 설명 할 수없는 시나리오에 부딪쳤다. 이 코드를 고려하십시오.

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

또한 "모호한"오류가 발생하므로 두 개의 후보 만있는 경우에도 적용 가능한 오버로드 된 방법의 수는 중요하지 않습니다. 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는 AS, 모호한 방법 참조입니다 add방법은 그것도 방법을 선택 도움이되지 수, 너무 과부하가 있지만, 방법을 참조 어쨌든 다른 코드에 의해 처리받을 수 있습니다. 명확하게 aList::contains변경하거나로 변경 List하여 명확하게 Collection하기 위해 addEclipse 설치의 결과가 변경되지 않았습니다 (사용했습니다 2019-06).

이클립스 컴파일러는 올바르게에 해결 default방법 이가 있기 때문에, 가장 구체적인 방법 에 따라 Java 언어 사양 15.12.2.5은 :

최대로 구체적인 방법 중 하나가 구체적 일 경우 (즉, abstract기본값이 아닌 경우) 가장 구체적인 방법입니다.

javac(기본적으로 Maven 및 IntelliJ에서 사용) 메서드 호출이 모호하다는 것을 나타냅니다. 그러나 Java Language Specification에 따르면 두 가지 방법 중 하나가 가장 구체적인 방법이므로 모호하지 않습니다.

암시 적 으로 형식화 된 람다 식은 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의 많은 놀라움에 좋습니다. 복잡함은 인식 된 이득에 비례하지 않습니다.