用像 Collection<?> 这样的通配符替换像 Collection 这样的原始类型是否向后兼容？

Question

我是某个开源库的作者。其中一个公共接口具有使用 Collection 等原始类型的方法，例如：

public StringBuilder append(..., Collection value);

我收到Collection is a raw type. References to generic type Collection<E> should be parameterized 警告。

我正在考虑修复这些警告。实现实际上并不关心集合中元素的类型。所以我在考虑替换Collection<?>。

但是，这些方法是我的库的公共接口的一部分。客户端代码可以调用这些方法或提供这些公共接口的自己的实现，从而实现这些方法。恐怕将Collection 更改为Collection<?> 会破坏客户端代码。所以这是我的问题。

如果我在公共界面中更改Collection -> Collection<?>，可能会导致：

• 客户端代码中出现编译错误？
• 已编译的现有客户端代码中出现运行时错误？

Answer 1

您不会在运行时遇到任何问题，因为泛型类型已从二进制文件中删除——请参阅：https://docs.oracle.com/javase/tutorial/java/generics/erasure.html

Collection<?> 和Collection 的编译时间相同，您也不会有任何问题。 -- 见：https://docs.oracle.com/javase/tutorial/extra/generics/legacy.html

Answer 2

1. Collection 是任何类型的集合（即它可以包含任何类型的元素：整数、字符串、对象...）
2. Collection<?> 是某种特定类型的集合。

客户端代码不会有任何编译错误或运行时错误。因为当您将集合传递给Collection<?> 时，它会被视为Collection<Object>

Answer 3

在运行时进行这种替换是不安全的。

我或许应该更准确地说，这种变化本身是安全的；但它鼓励的后续更改可能会导致失败。

Collection 和 Collection<?> 之间的区别在于前者可以添加任何内容，而后者除了文字 null 之外不能添加任何内容。

因此，当前覆盖您的方法的人可能会执行以下操作：

@Override
public StringBuilder append(Collection value) {
  value.add(Integer.valueOf(1));
  return new StringBuilder();
}

（我不知道该方法的目的是什么；这是一个病态的例子。这看起来确实是他们不应该做的事情，但这与他们不一样没有这样做）。

现在，假设这个方法是这样调用的：

ArrayList c = new ArrayList();
thing.append(c);
c.get(0).toString();

（再说一次，我不知道它是如何真正使用的。请耐心等待）

如果您在超类中将方法签名更改为appendCollection<?>，也许令人惊讶的是（*），您不需要将子类也更新为泛型：上面的append 方法将继续编译。

看到基类中参数的新泛型类型，您可能会认为您现在可以使此调用代码非原始：

ArrayList<Double> c = new ArrayList<>();
thing.append(c);
c.get(0).toString();

现在，这里的问题是如何评估最后一行：那里有一个隐式转换。它实际上会被评估为：

Double d = (Double) c.get(0);
d.toString();

尽管事实上您可以在 Object 上调用 toString()：编译器仍会插入一个 checkcast，以擦除列表元素类型。这会在运行时失败，因为列表中的最后一项是整数，而不是 Double。

关键是没有为原始类型的版本插入演员表。这将被评估为：

Object d = (Object) c.get(0);
d.toString();

这在运行时不会失败，因为任何东西都可以转换为对象（事实上，根本不会转换；我只是为了对称而插入它）。

这并不是说这样的调用代码在设置参数Collection<?>之前就不能存在：它当然可以，而且它在运行时已经失败了。但我要强调的一点是，将这个方法参数设为泛型可能会给人一种错误的印象，即将现有的原始调用代码转换为使用泛型是安全的，这样做会导致它失败。

所以...除非您可以保证子类中没有此类插入，或者您已明确记录不应在第三种方法中修改集合，否则此更改将不安全。

---

(*) 这是由于在 JLS Sec 8.4.2 中定义了覆盖等效性，其中明确考虑了擦除。