我注意到使用泛型和 lambda 重载方法时有一种奇怪的行为。这个类工作正常:

  public <T> void test(T t) { }

  public <T> void test(Supplier<T> t) { }

  public void test() {
    test("test");
    test(() -> "test");
  }

没有模棱两可的方法调用。但是，将其更改为此会使第二个调用不明确:

  public <T> void test(Class<T> c, T t) { }

  public <T> void test(Class<T> c, Supplier<T> t) { }

  public void test() {
    test(String.class, "test");
    test(String.class, () -> "test"); // this line does not compile
  }

这怎么可能？为什么添加另一个参数会导致方法解析不明确？为什么它在第一个示例中可以区分 Supplier 和 Object，而在第二个示例中却不能？

编辑:这是使用 1.8.0_121。这是完整的错误消息:

error: reference to test is ambiguous
    test(String.class, () -> "test");
    ^
  both method <T#1>test(Class<T#1>,T#1) in TestFoo and method <T#2>test(Class<T#2>,Supplier<T#2>) in TestFoo match
  where T#1,T#2 are type-variables:
    T#1 extends Object declared in method <T#1>test(Class<T#1>,T#1)
    T#2 extends Object declared in method <T#2>test(Class<T#2>,Supplier<T#2>)
/workspace/com/test/TestFoo.java:14: error: incompatible types: cannot infer type-variable(s) T
    test(String.class, () -> "test");
        ^
    (argument mismatch; String is not a functional interface)
  where T is a type-variable:
    T extends Object declared in method <T>test(Class<T>,T)

最佳答案

如果我对 Java SE 8 的 JLS 第 15 章和第 18 章的理解是正确的，那么您的问题的关键在于以下引自段落 15.12.2 的内容。 :

Certain argument expressions that contain implicitly typed lambda expressions (§15.27.1) or inexact method references (§15.13.1) are ignored by the applicability tests, because their meaning cannot be determined until a target type is selected.

当 Java 编译器遇到类似 test(() -> "test") 的方法调用表达式时，它必须搜索可以将此方法调用分派(dispatch)到的可访问(可见)和适用(即具有匹配签名)的方法。在你的第一个例子中，<T> void test(T)和 <T> void test(Supplier<T>)可访问和适用 w.r.t. test(() -> "test")方法调用。在这种情况下，当有多种匹配方法时，编译器会尝试确定最具体的一种。现在，虽然这种对通用方法的确定(如 JLS 15.12.2.5和 JLS 18.5.4 ) 相当复杂，我们可以使用从 15.12.2.5 开始的直觉:

The informal intuition is that one method is more specific than another if any invocation handled by the first method could be passed on to the other one without a compile-time error.

因为对<T> void test(Supplier<T>)的任何有效调用我们可以找到类型参数 T 的对应实例化在<T> void test(T) , 前者比后者更具体。

现在，令人惊讶的部分是在你的第二个例子中，<T> void test(Class<T>, Supplier<T>)和 <T> void test(Class<T>, T)被认为适用于方法调用 test(String.class, () -> "test") ，尽管我们很清楚，后者不应该。问题是，如上所述，编译器在存在隐式类型的 lambda 时表现得非常保守。具体见JLS 18.5.1 :

A set of constraint formulas, C, is constructed as follows.

...

• To test for applicability by strict invocation:

If k ≠ n, or if there exists an i (1 ≤ i ≤ n) such that e_i is pertinent to applicability (§15.12.2.2) (...) Otherwise, C includes, for all i (1 ≤ i ≤ k) where e_i is pertinent to applicability, ‹e_i → F_i θ›.

• To test for applicability by loose invocation:

If k ≠ n, the method is not applicable and there is no need to proceed with inference.

Otherwise, C includes, for all i (1 ≤ i ≤ k) where e_i is pertinent to applicability, ‹e_i → F_i θ›.

和JLS 15.12.2.2 :

An argument expression is considered pertinent to applicability for a potentially applicable method m unless it has one of the following forms:

• An implicitly typed lambda expression (§15.27.1).

...

因此，作为参数传递的隐式类型 lambda 的约束不参与在方法适用性检查的上下文中解决类型推断。

现在，如果我们假设这两种方法都适用，那么问题 - 以及此示例与上一个示例之间的区别 - 就是这些方法都不是更具体的。存在对 <T> void test(Class<T>, Supplier<T>) 有效的调用但不适用于 <T> void test(Class<T>, T) ，反之亦然。

这也解释了为什么 test(String.class, (Supplier<String>) () -> "test");编译，正如@Aominè 在上面的评论中提到的那样。 (Supplier<String>) () -> "test")是一个显式类型的 lambda，因此被认为与适用性相关，编译器能够正确推断出这些方法中只有一个适用，并且不会发生冲突。

关于java - 使用泛型和 lambda 重载方法时调用方法不明确，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/48349055/