将原始类型（如 Collection）替换为通配符（如 Collection<）是否向后兼容？>？

java generics

2022-09-04 02:34:52

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

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

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

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

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

如果我在公共界面中更改 ->，这是否会导致：CollectionCollection<?>

答案 1

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

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

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

因此，当前正在重写您的方法的人可能会执行以下操作：

@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();

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

关键的一点是，原始类型版本没有插入强制转换。这将像这样评估：

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

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

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

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

(*)这是由于 JLS Sec 8.4.2 中超等效性的定义而产生的，其中明确考虑了擦除。

答案 2

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

您也不会在编译时遇到任何问题，并且是等效的。-- 参见：https://docs.oracle.com/javase/tutorial/extra/generics/legacy.htmlCollection<?>Collection