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。