仿制药中的仿制药是如何工作的？

Question

虽然我确实理解泛型的一些常见情况，但我在下面的例子中遗漏了一些东西。

我有以下课程

1 public class Test<T> {
2   public static void main(String[] args) {
3     Test<? extends Number> t = new Test<BigDecimal>();
4     List<Test<? extends Number>> l =Collections.singletonList(t);
5   }
6 }

第4行给出了错误

Type mismatch: cannot convert from List<Test<capture#1-of ? extends Number>> 
to List<Test<? extends Number>>`. 

显然，编译器认为不同的？并不真正相等。而我的直觉告诉我，这是正确的。

如果第4行是合法的，谁能提供一个我会得到运行时错误的例子？

编辑：

为了避免混淆，我用一个具体的赋值替换了第3行中的=null

Answer 1

也许这可以解释编译器的问题：

List<? extends Number> myNums = new ArrayList<Integer>();

这个属型通配符列表可以保存从Number扩展的任何元素。所以可以给它分配一个整数列表。但是现在我可以给myNums添加一个双精度，因为双精度也从Number扩展，这将导致运行时问题。所以编译器禁止对myNums的每一次写访问，我只能在上面使用读方法，因为我只知道我得到的任何东西都可以转换为Number。

因此，编译器抱怨使用这种通配符泛型可以做很多事情。有时他对你能保证安全的事情很生气。

但幸运的是，有一个技巧可以绕过这个错误，这样你就可以自己测试什么可能会打破这个错误：

public static void main(String[] args) {

    List<? extends Number> list1 = new ArrayList<BigDecimal>();
    List<List<? extends Number>> list2 = copyHelper(list1);


}

private static <T> List<List<T>> copyHelper(List<T> list) {
    return Collections.singletonList(list);

}

Answer 2

没有潜在的运行时错误，只是超出了编译器静态确定错误的能力。每当你引起类型推断时，它就会自动生成一个新的

因此，如果通过指定

List<Test<? extends Number>> l = Collections.<Test<? extends Number>>singletonList(t);

它很好用。生成的代码与您的调用是合法的没有什么不同，这只是编译器的一个限制，它自己无法解决这个问题。

推理创建捕获和捕获不兼容的规则阻止了本教程示例编译，然后在运行时崩溃：

public static void swap(List<? extends Number> l1, List<? extends Number> l2) {
    Number num = l1.get(0);
    l1.add(0, l2.get(0));
    l2.add(0, num);
}

是的，语言规范和编译器可能会变得更复杂，以区分您的示例，但事实并非如此，而且它足够简单，可以解决这个问题。

Answer 3

正如肯尼在评论中指出的，你可以通过以下方式绕过这个问题：

List<Test<? extends Number>> l =
    Collections.<Test<? extends Number>>singletonList(t);

这立即告诉我们，操作并不不安全，它只是有限推断的受害者。如果它是不安全的，上述内容就无法编译。

由于在上述泛型方法中使用显式类型参数只是作为提示，因此我们可以推测，这里需要它是推理机的一个技术限制。事实上，Java 8编译器目前计划对类型推断进行许多改进。我不确定你的具体案件是否会得到解决。

我们得到的编译错误表明集合的类型参数T。singletonList被推断为捕获

• 认为通配符捕获的最佳方式（捕获

假设我们想要一种方法，将列表移到后面。然后假设我们的列表具有未知（通配符）类型。

public static void main(String... args) {
    List<? extends String> list = new ArrayList<>(Arrays.asList("a", "b", "c"));
    List<? extends String> cycledTwice = cycle(cycle(list));
}

public static <T> List<T> cycle(List<T> list) {
    list.add(list.remove(0));
    return list;
}

这很好，因为T被解析为捕获

public static List<? extends String> cycle(List<? extends String> list) {
    list.add(list.remove(0));
    return list;
}

它将无法编译，因为我们还没有通过将捕获分配给类型参数来使其可访问。

因此，这就开始解释为什么singletonList的消费者会受益于类型推断器将T解析为测试

为什么我们不能分配一个列表

如果我们考虑到<代码>捕获的事实

public static <T extends Number> List<Test<? extends Number>> assign(List<Test<T>> t) {
    return t;
} 

这是不编译的一个很好的理由。如果是这样的话，那么这将是可能的：

//all this would be valid
List<Test<Double>> doubleTests = null;
List<Test<? extends Number>> numberTests = assign(doubleTests);

Test<Integer> integerTest = null;
numberTests.add(integerTest); //type error, now doubleTests contains a Test<Integer>

让我们回到开头。如果上述情况不安全，那么为什么允许这样做：

List<Test<? extends Number>> l =
    Collections.<Test<? extends Number>>singletonList(t);

为此，它意味着允许以下操作：

Test<capture<? extends Number>> capturedT;
Test<? extends Number> t = capturedT;

这不是有效的语法，因为我们不能显式引用捕获，所以让我们使用与上面相同的技术来评估它！让我们将捕获绑定到“分配”的另一个变体：

public static <T extends Number> Test<? extends Number> assign(Test<T> t) {
    return t;
} 

这是成功编译的。不难看出为什么它应该是安全的。这正是类似于

List<? extends Number> l = new List<Double>();