22

虽然我确实了解泛型的一些极端情况，但我在以下示例中遗漏了一些东西。

我有以下课程

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 行是合法的，我会得到一个运行时错误？

编辑：

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

4

5 回答 5

22

正如肯尼在他的评论中指出的那样，您可以通过以下方式解决这个问题：

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

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

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

那么，究竟发生了什么？

好吧，我们得到的编译错误表明 的类型参数T被Collections.singletonList推断为capture<Test<? extends Number>>. 换句话说，通配符有一些与之关联的元数据，将其链接到特定的上下文。

  • capture<? extends Foo>将通配符 ( ) 视为捕获的最佳方法是将其视为具有相同边界的未命名类型参数（即<T extends Foo>，但无法引用T）。
  • “释放”捕获功能的最佳方法是将其绑定到泛型方法的命名类型参数。我将在下面的示例中对此进行演示。请参阅 Java 教程“通配符捕获和辅助方法”（感谢 @WChargin 的参考）以进一步阅读。

假设我们想要一个移动列表的方法，并将其换到后面。然后让我们假设我们的列表有一个未知（通配符）类型。

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被解析为capture<? extends String>，而不是? extends String。如果我们改为使用这种非通用的循环实现：

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

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

所以这开始解释为什么消费者singletonList会受益于类型推断器解析T为Test<capture<? extends Number>，从而返回 aList<Test<capture<? extends Number>>>而不是 a List<Test<? extends Number>>。

但是为什么不能将一个分配给另一个呢？

为什么我们不能将 a 分配List<Test<capture<? extends Number>>>给 a List<Test<? extends Number>>？

好吧，如果我们考虑capture<? extends Number>一个等效于匿名类型参数的事实，其上限为Number，那么我们可以将这个问题变成“为什么以下内容不能编译？” （它没有！）：

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;

好吧，这不是有效的语法，因为我们不能明确引用捕获，所以让我们使用与上面相同的技术来评估它！让我们将捕获绑定到“assign”的不同变体：

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

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

List<? extends Number> l = new List<Double>();
于 2013-05-08T22:22:16.173 回答
8

没有潜在的运行时错误，它只是在编译器静态确定的能力之外。每当您进行类型推断时，它都会自动生成 的新捕获<? extends Number>，并且两个捕获不被认为是等效的。

因此，如果您通过指定<T>它从调用 singletonList 中删除推理：

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);
}

是的，语言规范和编译器可能会变得更加复杂，以除此之外告诉您的示例，但事实并非如此，而且它很简单可以解决。

于 2013-05-08T22:08:31.073 回答
0

原因是编译器不知道您的通配符类型是相同的类型。

它也不知道您的实例是null. 虽然null是所有类型的成员，但编译器在类型检查时只考虑声明的类型，而不考虑变量的值可能包含的内容。

如果代码执行，它不会导致异常，但这只是因为该值为空。仍然存在潜在的类型不匹配，这就是编译器的工作 - 禁止类型不匹配。

于 2013-05-08T20:46:27.597 回答
0

看看类型擦除。问题是“编译时间”是 Java 必须强制执行这些泛型的唯一机会，所以如果它让它通过它就无法判断您是否尝试插入无效的东西。这实际上是一件好事，因为这意味着一旦程序编译，泛型就不会在运行时产生任何性能损失。

让我们尝试以另一种方式查看您的示例（让我们使用两种扩展 Number 但行为非常不同的类型）。考虑以下程序：

import java.math.BigDecimal;
import java.util.*;

public class q16449799<T extends Number> {
  public T val;

  public static void main(String ... args) {
    q16449799<BigDecimal> t = new q16449799<>();
    t.val = new BigDecimal(Math.PI);

    List<q16449799<BigDecimal>> l = Collections.singletonList(t);
    for(q16449799<BigDecimal> i : l) {
      System.out.println(i.val);
    }
  }
}

这输出（正如人们所期望的那样）：

3.141592653589793115997963468544185161590576171875

现在假设您提供的代码没有导致编译器错误：

import java.math.BigDecimal;
import java.util.concurrent.atomic.AtomicLong;

public class q16449799<T extends Number> {
  public T val;

  public static void main(String ... args) {
    q16449799<BigDecimal> t = new q16449799<>();
    t.val = new BigDecimal(Math.PI);

    List<q16449799<AtomicLong>> l = Collections.singletonList(t);
    for(q16449799<AtomicLong> i : l) {
      System.out.println(i.val);
    }
  }
}

你期望输出是什么？您无法合理地将 BigDecimal 强制转换为 AtomicLong（您可以从 BigDecimal 的值构造 AtomicLong，但强制转换和构造是不同的事情，泛型被实现为编译时糖以确保强制转换成功）。至于@KennyTM 的评论，当您最初的示例时正在寻找一个具体类型，但尝试编译它：

import java.math.BigDecimal;
import java.util.*;

public class q16449799<T> {
  public T val;

  public static void main(String ... args) {
    q16449799<? extends Number> t = new q16449799<BigDecimal>();

    t.val = new BigDecimal(Math.PI);

    List<q16449799<? extends Number>> l = Collections.<q16449799<? extends Number>>singletonList(t);
    for(q16449799<? extends Number> i : l) {
      System.out.println(i.val);
    }
  }
}

当您尝试将值设置为 时，这将出错t.val。

于 2013-05-08T21:05:30.213 回答
0

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

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

这个通用通配符列表可以包含从 Number 扩展的任何元素。所以可以给它分配一个整数列表。但是现在我可以将 Double 添加到 myNums 因为 Double 也是从 Number 扩展的，这会导致运行时问题。所以编译器禁止对 myNums 的每次写访问，我只能对它使用 read 方法，因为我只知道我得到的东西可以转换为 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);

}
于 2013-05-08T21:15:23.023 回答