下面的简单类(repo 重现它):

import static org.hamcrest.*;
import static org.junit.Assert.assertThat;
import java.util.*;
import org.junit.Test;

public class TestGenerics {
  @Test
  public void thisShouldCompile() {
    List<String> myList = Arrays.asList("a", "b", "c");
    assertThat("List doesn't contain unexpected elements", myList, not(anyOf(hasItem("d"), hasItem("e"), hasItem("f"))));
  }
}

行为取决于 JDK 版本:

• 在 JDK 中正确编译<=8(用 7="" 和="" 8="">
• 使用 JDK 9+ 编译失败(使用 9、10 和 11 EA 测试)

出现以下错误:

[ERROR] /tmp/jdk-issue-generics/src/test/java/org/alostale/issues/generics/TestGenerics.java:[17,17] no suitable method found for assertThat(java.lang.String,java.util.List<java.lang.String>,org.hamcrest.Matcher<java.lang.Iterable<? super java.lang.Object>>)
    method org.junit.Assert.<T>assertThat(java.lang.String,T,org.hamcrest.Matcher<? super T>) is not applicable
      (inference variable T has incompatible bounds
        upper bounds: java.lang.String,java.lang.Object
        lower bounds: capture#1 of ? super T?,capture#2 of ? super java.lang.Object,capture#3 of ? super java.lang.Object,java.lang.Object,java.lang.String,capture#4 of ? super T?)
    method org.junit.Assert.<T>assertThat(T,org.hamcrest.Matcher<? super T>) is not applicable
      (cannot infer type-variable(s) T
        (actual and formal argument lists differ in length))

这是 JDK 9 中的一些预期变化还是一个错误？

我可以通过这种方式将匹配器提取到类型变量，并且它会起作用:

    Matcher<Iterable<? super String>> m1 = hasItem("d");
    Matcher<Iterable<? super String>> m2 = hasItem("e");
    Matcher<Iterable<? super String>> m3 = hasItem("f");
    assertThat(myList, not(anyOf(m1, m2, m3)));

但问题仍然是:javac <=8 是否能够推断类型，但不能在="" 9+="">

最佳答案

经过一些研究，我相信我们可以将其排除为 Junit 或 hamcrest 问题。事实上，这似乎是一个 JDK 错误。以下代码在 JDK > 8 中无法编译:

AnyOf<Iterable<? super String>> matcher = CoreMatchers.anyOf(
    CoreMatchers.hasItem("d"), CoreMatchers.hasItem("e"), CoreMatchers.hasItem("f"));

Error:(23, 63) java: incompatible types: inference variable T has incompatible bounds
equality constraints: java.lang.String
lower bounds: java.lang.Object,java.lang.String

将其转换为不使用库的 MCVE:

class Test {
    class A<S> { } class B<S> { } class C<S> { } class D { }

    <T> A<B<? super T>> foo() { return null; }

    <U> C<U> bar(A<U> a1, A<? super U> a2) { return null; }

    C<B<? super D>> c = bar(foo(), foo());
}

使用 bar 中的单个变量可以实现类似的效果，这会导致上限相等约束，而不是下限:

class Test {
    class A<S> { } class B<S> { } class C<S> { } class D { }

    <T> A<B<? super T>> foo() { return null; }

    <U> C<U> bar(A<? super U> a) { return null; }

    C<B<? super D>> c = bar(foo());
}

Error:(21, 28) java: incompatible types: inference variable U has incompatible bounds
equality constraints: com.Test.B<? super com.Test.D>
upper bounds: com.Test.B<? super capture#1 of ? super com.Test.D>,java.lang.Object

看起来当 JDK 试图合理化 时？ super U 它无法找到要使用的正确通配符类。更有趣的是，如果你完全指定 foo 的类型，那么编译器实际上会成功。 这对于 MCVE 和原始帖子都适用:

// This causes compile to succeed even though an IDE will call it redundant
C<B<? super D>> c = bar(this.<D>foo(), this.<D>foo());

就像您介绍的情况一样，将执行分成多行将产生正确的结果:

A<B<? super D>> a1 = foo();
A<B<? super D>> a2 = foo();
C<B<? super D>> c = bar(a1, a2);

因为有多种方法可以编写功能上等效的代码，并且考虑到只有其中一些可以编译，所以我的结论是这不是 JDK 的预期行为。在评估具有 super 限制的通配符时，某处存在错误。

我的建议是针对 JDK 8 编译现有代码，对于需要 JDK > 8 的新代码，完全指定通用值。

关于java - 泛型行为在 JDK 8 和 9 中有所不同，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/50928300/