java – 泛型行为在JDK 8和9中有所不同

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了java – 泛型行为在JDK 8和9中有所不同，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含3031字，纯文字阅读大概需要5分钟。

内容图文

以下简单类(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"));

06001

把它变成一个不使用库的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());
}

06004

看起来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的预期行为.在具有超级绑定的通配符的评估中存在某个错误.

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

内容总结

以上是互联网集市为您收集整理的java – 泛型行为在JDK 8和9中有所不同全部内容，希望文章能够帮你解决java – 泛型行为在JDK 8和9中有所不同所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端