使用 lambda 和泛型时对方法的引用不明确

Question

我在以下代码中遇到错误，我认为它不应该存在...使用 JDK 8u40 编译此代码。

public class Ambiguous {
    public static void main(String[] args) {
        consumerIntFunctionTest(data -> {
            Arrays.sort(data);
        }, int[]::new);

        consumerIntFunctionTest(Arrays::sort, int[]::new);
    }

    private static <T> void consumerIntFunctionTest(final Consumer<T> consumer, final IntFunction<T> generator) {

    }

    private static <T> void consumerIntFunctionTest(final Function<T, ?> consumer, final IntFunction<T> generator) {

    }
}

错误如下：

Error:(17, 9) java: 对 consumerIntFunctionTest 的引用不明确 net.tuis.ubench.Ambiguous 中的方法 consumerIntFunctionTest(java.util.function.Consumer,java.util.function.IntFunction) 和 net 中的方法 consumerIntFunctionTest(java.util.function.Function,java.util.function.IntFunction) .tuis.ubench.Ambiguous 匹配

错误发生在以下行：

consumerIntFunctionTest(Arrays::sort, int[]::new);

我相信应该没有错误，因为所有Arrays::sort 引用都是void 类型的，并且它们都没有返回值。如您所见，当我显式扩展 Consumer<T> lambda 时，它确实工作。

这真的是 javac 中的一个错误，还是 JLS 声明 lambda 在这种情况下无法自动展开？如果是后者，我仍然认为这很奇怪，因为 consumerIntFunctionTest 与第一个参数 Function<T, ?> 不应该匹配。

Answer 1

在你的第一个例子中

consumerIntFunctionTest(data -> {
        Arrays.sort(data);
    }, int[]::new);

lambda 表达式有一个void-compatible 块，可以通过表达式的结构来识别，而无需解析实际类型。

相比之下，在示例中

consumerIntFunctionTest(Arrays::sort, int[]::new);

必须解析方法引用以找出它是否符合void 函数（Consumer）或值返回函数（Function）。这同样适用于简化的 lambda 表达式

consumerIntFunctionTest(data -> Arrays.sort(data), int[]::new);

这可能是void- 兼容或值-兼容，这取决于解析的目标方法。

问题是解决方法需要知道所需的签名，这应该通过目标类型来确定，但是在知道泛型方法的类型参数之前，目标类型是未知的。虽然理论上两者都可以同时确定，但（仍然非常复杂）过程已在规范中进行了简化，因为首先执行方法重载解析，最后应用类型推断（请参阅JLS §15.12.2）。因此，类型推断可以提供的信息不能用于解决重载决议。

但请注意15.12.2.1. Identify Potentially Applicable Methods 中描述的第一步包含：

根据以下规则，表达式可能与目标类型兼容：

• 如果满足以下所有条件，则 lambda 表达式（第 15.27 节）可能与功能接口类型（第 9.8 节）兼容：

  • 目标类型的函数类型的元数与 lambda 表达式的元数相同。

  • 如果目标类型的函数类型返回 void，则 lambda 主体是语句表达式（第 14.8 节）或 void 兼容块（第 15.27.2 节）。

  • 如果目标类型的函数类型具有（非 void）返回类型，则 lambda 主体是表达式或值兼容块（第 15.27.2 节）。

• 方法引用表达式（第 15.13 节）可能与函数接口类型兼容，如果类型的函数类型元数为 n，则至少存在一个可能适用于元数为 n 的方法引用表达式的方法（第 15.13 节）。 1)，并且下列情况之一为真：

• 方法引用表达式的格式为 ReferenceType :: [TypeArguments] Identifier，并且至少一个可能适用的方法是 i) 静态并支持 arity n，或 ii) 非静态并支持 arity n-1。

• 方法引用表达式具有其他形式，并且至少有一个可能适用的方法不是静态的。

…

^{潜在适用性的定义超出了基本的数量检查，还考虑了功能接口目标类型的存在和“形状”。在某些涉及类型参数推断的情况下，作为方法调用参数出现的 lambda 表达式在重载决议之后才能正确键入。}

因此，在第一个示例中，其中一个方法是按 lambda 的形状排序的，而在方法引用或由唯一调用表达式组成的 lambda 表达式的情况下，两种可能适用的方法都会承受第一个选择过程并产生“类型推断之前出现“模糊”错误，以帮助查找目标方法以确定它是 void 还是返回值的方法。

请注意，就像使用 x->{ foo(); } 使 lambda 表达式明确地与 void 兼容一样，您可以使用 x->( foo() ) 使 lambda 表达式明确地值兼容。

---

您可以进一步阅读 this answer 解释说组合类型推断和方法重载解决方案的这种限制是一个深思熟虑（但不容易）的决定。

Answer 2

使用方法引用，你可以有完全不同的参数类型，更不用说返回类型了，如果你有另一个方法与arity（参数的数量）匹配，仍然会得到这个。

例如：

static class Foo {

    Foo(Consumer<Runnable> runnableConsumer) {}

    Foo(BiFunction<Long, Long, Long> longAndLongToLong) {}
}

static class Bar {

    static void someMethod(Runnable runnable) {}

    static void someMethod(Integer num, String str) {}
}

Bar.someMethod() 不可能满足longAndLongToLong，但是下面的代码在歧义方面发出了相同的编译错误：

new Foo(Bar::someMethod);

Holger 的回答很好地解释了这背后的 JLS 中的逻辑和相关条款。

二进制兼容性如何？

考虑Foo 构造函数的longAndLongToLong 版本是否不存在但后来在库更新中添加，或者Bar.someMethod() 的两个参数版本不存在但后来添加：突然之前编译代码可能会因此而破裂。

这是方法重载的不幸副作用，甚至在 lambda 或方法引用出现之前，类似的问题就已经影响了普通方法调用。

幸运的是，保留了二进制兼容性。相关条款在13.4.23. Method and Constructor Overloading：

添加重载现有方法或构造函数的新方法或构造函数不会破坏与预先存在的二进制文件的兼容性。每次调用使用的签名是在编译这些现有二进制文件时确定的； ....

虽然添加新的重载方法或构造函数可能会在下一次编译类或接口时导致编译时错误，因为没有最具体的方法或构造函数（第 15.12.2.5 节），但在以下情况下不会发生此类错误程序被执行，因为在执行时没有进行重载决议。