java - 编译器不推断 System.out::println 功能接口(interface)

Question

我有一个重载方法，它采用两个不同的功能接口(interface)作为参数(Runnble 和 Supplier)。 System.out.println 显然只兼容Runnable，因为它是一个void 方法。然而编译器仍然声称调用是不明确的。这怎么可能？

import java.util.function.Supplier;

public class GenericLambdas {
    public static void main(String[] args) {
        wrap(System.out::println);   // Compiler error here
        wrap(() -> {});              // No error
        wrap(System.out::flush);     // No error
    }

    static <R> void wrap(Supplier<R> function) {}

    static void wrap(Runnable function) {}
}

编译器输出:

Error:Error:line (5)java: reference to wrap is ambiguous
    both method <R>wrap(java.util.function.Supplier<R>) in GenericLambdas and method wrap(java.lang.Runnable) in GenericLambdas match 
Error:Error:line (5)java: incompatible types: cannot infer type-variable(s) R
    (argument mismatch; bad return type in method reference
      void cannot be converted to R)

基于第二个错误(参数不匹配，void 无法转换为 R)，编译器难道不能消除调用的歧义吗？这将解决两个编译器错误(因为它既不会模棱两可，也不会尝试将 void 转换为 R)。

为什么 () -> {} 和 System.out::flush 能够解析？它们与 System.out.println 具有相同的签名。假设 System.out.println 被带参数的版本重载，但这些重载版本都不匹配 Supplier 或 Runnable，所以我看不出它们在这里有什么意义。

编辑:

看起来这确实编译并运行了 Eclipse compiler .哪个编译器是正确的，或者是否允许任何一种行为？

Answer 1

寻找合适版本的 println 会忽略返回类型。参见 JLS 15.13.2 .包含它是没有意义的，因为不可能有具有相同参数但返回类型不同的方法的两个版本。但是现在编译器遇到了问题:Supplier#get 和 Runnable#run 需要相同的参数(无)。所以有一个 println 可以匹配两者。请记住，在此阶段，编译器仅尝试查找方法。编译器基本上遇到了与这段代码相同的问题:

public static void main(String[] args) {
 test(System.out::println);
}

public static void test(Runnable r) {}
public static void test(Consumer<String> r) {}

println() 匹配 Runnable#run 而 println(String) 匹配 Consumer#accept。我们没有提供目标类型，所以情况不明确。

选择方法后，可以正确推断出目标类型，在这个阶段返回类型是相关的。参见 JLS 15.13.2 .所以这段代码当然会失败:

public static void main(String[] args) {
    wrap(System.out::println);
}

static <R> void wrap(Supplier<R> function) {}

编译器在检测到歧义时会立即抛出错误。虽然 bug report已经提出并接受了这种行为，那里的评论表明 Oracle 的 JDK 可能比 ECJ 更忠实地遵守 JLS(尽管它的行为更好)。后来bug report ，在这个 SO 问题的背后提出，被解决为“不是问题”，表明经过内部辩论，Oracle 已经决定 javac 的行为是正确的。