Java Generics：在这里使用通配符有什么好处？

Question

Collections.fill方法具有以下 header：

public static <T> void fill(List<? super T> list, T obj)

为什么需要通配符？ 以下 header 似乎也可以正常工作：

public static <T> void fill(List<T> list, T obj)

我看不出需要通配符的原因； 如下代码适用于第二个 header 以及第一个：

List<Number> nums = new ArrayList<>();
Integer i = 43;
fill(nums, i); //fill method written using second header

我的问题是：对于第一个fill的具体调用，而不是第二个？ 如果没有这样的调用，为什么要包含通配符？ 在这种情况下，通配符不会使方法更简洁，也不会增加可读性（在我看来）。

Answer 1

这是因为 inheritance 在某些情况下很有用。

例如，如果您具有以下 class 结构：

public class Parent {
  //some code
}

public class Child extends Parent {
  //some another code
}

您可以使用第一种方法编写：

List<Child> children = new ArrayList<>();
Parent otherParentObject = new Parent(); //after this line, set the values for the class
List<Parent> outParentList = fill(children, otherParentObject); //fill method using first signature;

Answer 2

这是一个非常好的问题，并且已经猜到了简单的答案：

对于当前版本的fill(List<? super T> list, T obj)没有这样的输入会被拒绝，因为签名更改为fill(List<T> list, T obj) ，所以没有受益，开发人员可能遵循 PECS 原则

上述陈述源于以下原则：如果存在这样的类型X使得X是T的超类型，则List<X>是List<? super T> List<? super T>因为类型逆变。 因为我们总能找到这样的X （在最坏的情况下是Object类） - 编译器可以推断出合适的List<X>参数类型。

因此，知道这一事实我们可以干扰编译器并使用“类型见证”自己推断类型，因此代码会中断：

List<Object> target = new ArrayList<>();
//Compiles OK as we can represent List<Object> as List<? super Integer> and it fits
Collections.<Integer>fill(target, 1);

//Compilation error as List<Object> is invariant to List<Integer> and not a valid substitute
Collections.<Integer>fillNew(target, 1);

这当然纯粹是理论上的，没有人会在他们的头脑中使用类型参数。

然而

在回答“在这里使用通配符有什么好处？ ”这个问题时，我们只考虑了等式的一方面——我们，方法的消费者和我们的经验，而不是库开发人员。

因此，这个问题有点类似于为什么Collections.enumeration(final Collection<T> c)被声明为它的方式而不是enumeration(Collection<T> c)因为final对最终用户来说似乎是多余的。

我们可以在这里推测真正的意图，但我可以给出一些主观原因：

1. 第一：使用List<? super T> List<? super T> （以及enumeration的final ）立即消除了代码的歧义，而对于<? super T> <? super T>特别是 - 表明只需要有关类型参数的部分知识并且list不能用于生成 T 的值，而只能用于使用它们，这很有用。 JLS 4.5.1。 参数化类型的 Arguments 类型

2. 其次：它为库所有者提供了一些自由来改进/更新方法，而不会破坏向后兼容性，同时符合现有的约束。

---

让我们做出一些假设的“改进”（我将调用使用List<T>作为fillNew的fill形式）： #1 决定是让方法返回obj值（用于填充列表）：

public static <T> void fill(List<? super T> list, T obj)
//becomes ↓↓↓
public static <T> T fill(List<? super T> list, T obj)

更新后的方法可以很好地用于fill签名，但对于fillNew - 现在推断的返回类型并不那么明显：

List<Number> target = new ArrayList<>();
Long val = fill(target, 1L); <<Here Long is the most specific type that fits both arguments
//Compilation error
Integer val = fillNew(target, 1); <<Here Number is, so it cannot be assigned back

//More exotic case:
Integer val = fill(asList(true), 0); //val is Integer as expected
Comparable<?> val = fillNew(asList(true), 0); val is now Comparable<?> as the most specific type 

#2 在T为Comparable<T>的情况下，决定添加一个重载版本的fill性能提高 10 倍：

/* Extremely performant 10x version */
public static <T extends Comparable<T>> void fill(List<? super T> list, T value)
/* Normal version */
public static void fill(List<? super T> list, T value)

List<Number> target = new ArrayList<>();
fill(target, 1);  <<< Here the more performant version is used as T inferred to Integer and it implements Comparable<Integer>
fillNew(target, 1); << Still uses the slow version just because T is inferred to Number which is not Comparable
    

总而言之 - 在我看来，当前的fill签名对所有各方（开发人员和图书馆设计师）来说都更加灵活/更具描述性

Answer 3

对于您的示例，它与您的基本<T>签名“工作”的原因是 Integer 也是一个数字。 唯一有效的“T”是T = Number ，然后整个事情就解决了。

在这种情况下，您对T obj参数的表达式是一个具体化类型：您有一个Integer 。 你可以有一个T代替。 也许你有这个：

class AtomicReference<T> {
  // The actual impl of j.u.concurrent.AtomicReference...
  // but with this one additional method:

  public void fillIntoList(List<? super T> list) {
    T currentValue = get();
    Collections.fill(list, currentValue);
  }
}

我可能想写这样的东西：

AtomicReference<String> ref = new AtomicReference<String>("hello");
List<CharSequence> texts = new ArrayList<>();

...

ref.fillIntoList(texts);

如果我假设fillIntoList方法只是在签名中包含List<T>将无法编译。 幸运的是，它确实可以编译代码。 如果Collections.fill方法没有完成<? super T> <? super T>事情，在我的Collections.fill方法中调用fillIntoList方法将失败。

任何这种情况的出现都是非常奇特的。 但它可以出现。 List<? super T> List<? super T>是这里严格意义上的高级签名——它可以做List<T>所做的一切，甚至更多，而且它在语义上也是正确的：当然我可以通过在每个插槽中写入一个对某物的引用来填充一个 list-of-foos如果 bar 是 foo 的孩子，那我肯定知道是 bar。