java - Eclipse 的 Function 上的 "extract to method"导致编译错误

Question

从具有 2 个字段、name 和 id、构造函数和 getter 的类 A 开始，我编写了此测试，该测试运行绿色:

@Test
public void test() {
    List<A> list = Arrays.asList(new A(null, "a"), new A(null, "b"));

    Collections.sort(list,
            Comparator
            .comparing(A::getName, Comparator.nullsLast(Comparator.naturalOrder()))
            .thenComparing(A::getId, Comparator.nullsLast(Comparator.reverseOrder())));

    assertThat(list.get(0).id, is("b"));
}

但是，如果我在 A::getName 上选择 Eclipse 的快速修复“提取到方法”:

我突然在下一行出现 2 个编译错误 (thenComparing(...)):

@Test
public void test() {
    List<A> list = Arrays.asList(new A(null, "a"), new A(null, "b"));

    Collections.sort(list,
            Comparator
            .comparing(extracted(), Comparator.nullsLast(Comparator.naturalOrder()))
            .thenComparing(A::getId, Comparator.nullsLast(Comparator.reverseOrder())));

    assertThat(list.get(0).id, is("b"));
}

private Function<? super A, ? extends String> extracted() {
    return A::getName;
}

说:

The type Test.A does not define getId(capture#1-of ? super Test.A) that is applicable here

和

The method thenComparing(Function<? super capture#1-of ? super Test.A,? extends U>, Comparator<? super U>) in the type Comparator is not applicable for the arguments (A::getId, Comparator<Comparable<? super Comparable<? super T>>>)

为什么会导致错误？我做错了什么？

Answer 1

这就是重构的罪魁祸首。它创建了两个新的通配符，需要在类型推断之前/期间捕获。此后，类型不再统一，推理也无法找到解决方案。

另一个错误是 javac 8 接受了此代码，但这已在 javac 9 中修复(我尝试构建 9-ea+118)。

在该版本中，javac 的错误消息如下:

error: no suitable method found for thenComparing(A::getId,Comparator<T#1>)
          .thenComparing(A::getId, Comparator.nullsLast(Comparator.reverseOrder())));
          ^
method Comparator.<U#1>thenComparing(Function<? super CAP#1,? extends U#1>,Comparator<? super U#1>) is not applicable
  (cannot infer type-variable(s) U#1
    (argument mismatch; invalid method reference
      method getId in class A cannot be applied to given types
        required: no arguments
        found: CAP#1
        reason: actual and formal argument lists differ in length))
method Comparator.<U#2>thenComparing(Function<? super CAP#1,? extends U#2>) is not applicable
  (cannot infer type-variable(s) U#2
    (actual and formal argument lists differ in length))
where T#1,T#2,U#1,T#3,U#2 are type-variables:
    T#1 extends T#2
    T#2 extends Comparable<? super T#2>
    U#1 extends Object declared in method <U#1>thenComparing(Function<? super T#3,? extends U#1>,Comparator<? super U#1>)
    T#3 extends Object declared in interface Comparator
    U#2 extends Comparable<? super U#2> declared in method <U#2>thenComparing(Function<? super T#3,? extends U#2>)
where CAP#1 is a fresh type-variable:
    CAP#1 extends Object super: A from capture of ? super A
Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output

编辑:javac 中的错误最有可能是 https://bugs.openjdk.java.net/browse/JDK-8039214这确实在版本 9 中得到了解决。据说这是处理 javac 未能正确处理通配符捕获的一系列相关错误的“主要错误”。在该错误中，建议将以下文本作为发行说明:

The javac compiler's behavior when handling wildcards and "capture" type variables has been improved for conformance to the language specification. This improves type checking behavior in certain unusual circumstances. It is also a source-incompatible change: certain uses of wildcards that have compiled in the past may fail to compile because of a program's reliance on the javac bug.

我相信在这两种情况(javac 9 和 ecj)中，有关 getId 的投诉是次要的，推理结果已经失败。

仔细观察，发现 getId 的错误是类型检查失败的主要原因:

• comparing(..) 的已解析类型是 Comparator<capture#1-of ? super A> (通过捕获 extracted() 的解析类型引发捕获)。
• 方法引用的目标类型 A::getName是 Function<? super capture#1-of ? super A,? extends U> (来自<U> Comparator<T> thenComparing(Function<? super T, ? extends U>, Comparator<? super U>)的第一个参数
• 此目标类型的非通配符参数化 ( JLS 9.9 ) 为 <capture#1-of ? super A, U> .
• 因此方法引用必须实现函数类型 U apply(capture#1-of ? super A)
• 使用 apply 的参数作为 getId 的接收者我们需要一个 A 类型的值，但我们只能保证提供的值是 A 的(未知)父类(super class)型.
• javac 恢复为期望给定类型的参数，而 getId不接受任何参数 -> 因此是有关参数列表长度的第一条消息。
• 因此getId未实现预期的功能类型。

这与 JDK-8039214 中的描述大致相符，即 javac 8 错误地使用了捕获的边界，而不是捕获本身。我说得含糊其辞，因为 bug 提到了上限，而这里 javac 8 似乎甚至使用了下限。