< 和有什么区别？扩展基础> 和 <T 扩展基础>？

Question

在这个例子中：

import java.util.*;

public class Example {
    static void doesntCompile(Map<Integer, List<? extends Number>> map) {}
    static <T extends Number> void compiles(Map<Integer, List<T>> map) {}

    static void function(List<? extends Number> outer)
    {
        doesntCompile(new HashMap<Integer, List<Integer>>());
        compiles(new HashMap<Integer, List<Integer>>());
    }
}

doesntCompile() 编译失败：

Example.java:9: error: incompatible types: HashMap<Integer,List<Integer>> cannot be converted to Map<Integer,List<? extends Number>>
        doesntCompile(new HashMap<Integer, List<Integer>>());
                      ^

而compiles() 被编译器接受。

This answer 解释说，唯一的区别是，与<? ...> 不同，<T ...> 允许您稍后引用该类型，但似乎并非如此。

在这种情况下<? extends Number> 和<T extends Number> 有什么区别，为什么第一个编译不出来？

Answer 1

通过使用以下签名定义方法：

static <T extends Number> void compiles(Map<Integer, List<T>> map) {}

并像这样调用它：

compiles(new HashMap<Integer, List<Integer>>());

您正在将 T 与您提供的类型相匹配。

在 jls §8.1.2 中，我们发现（有趣的部分由我加粗）：

泛型类声明定义了一组参数化类型（第 4.5 节），类型参数对类型参数部分的每个可能调用都有一个。所有这些参数化类型在运行时共享同一个类。

换句话说，T 类型与输入类型匹配并分配了Integer。签名将有效地变为static void compiles(Map<Integer, List<Integer>> map)。

说到doesntCompile方法，jls定义了子类型化规则（§4.5.1，我加粗了）：

如果 T2 表示的类型集在自反和传递闭包下可证明是 T1 表示的类型集的子集，则称一个类型参数 T1 包含另一个类型参数 T2，写作 T2

• ？扩展 T 则扩展 S

• ？扩展 T

• ？超级 T

• ？超级 T

• ？超级 T

• T

• T

• T

这意味着，? extends Number 确实包含Integer，甚至List<? extends Number> 包含List<Integer>，但Map<Integer, List<? extends Number>> 和Map<Integer, List<Integer>> 并非如此。有关该主题的更多信息，请访问in this SO thread。您仍然可以通过声明您期望List<? extends Number> 的子类型来使带有? 通配符的版本工作：

public class Example {
    // now it compiles
    static void doesntCompile(Map<Integer, ? extends List<? extends Number>> map) {}
    static <T extends Number> void compiles(Map<Integer, List<T>> map) {}

    public static void main(String[] args) {
        doesntCompile(new HashMap<Integer, List<Integer>>());
        compiles(new HashMap<Integer, List<Integer>>());
    }
}

Answer 2

在通话中：

compiles(new HashMap<Integer, List<Integer>>());

T 与 Integer 匹配，因此参数的类型是 Map<Integer,List<Integer>>。方法doesntCompile 的情况并非如此：无论调用中的实际参数是什么，参数的类型都保持Map<Integer, List<? extends Number>>；这不能从HashMap<Integer, List<Integer>> 分配。

更新

在doesntCompile 方法中，没有什么能阻止你做这样的事情：

static void doesntCompile(Map<Integer, List<? extends Number>> map) {
    map.put(1, new ArrayList<Double>());
}

很明显，它不能接受HashMap<Integer, List<Integer>> 作为参数。

Answer 3

演示的简单示例。同样的例子可以如下图所示。

static void demo(List<Pair<? extends Number>> lst) {} // doesn't work
static void demo(List<? extends Pair<? extends Number>> lst) {} // works
demo(new ArrayList<Pair<Integer>()); // works
demo(new ArrayList<SubPair<Integer>()); // works for subtype too

public static class Pair<T> {}
public static class SubPair<T> extends Pair<T> {}

List<Pair<? extends Number>> 是多级通配符类型，而List<? extends Number> 是标准通配符类型。

通配符类型List<? extends Number> 的有效具体实例包括Number 和Number 的任何子类型，而在List<Pair<? extends Number>> 的情况下，它是类型参数的类型参数并且本身具有泛型类型的具体实例.

泛型是不变的，所以Pair<? extends Number> 通配符类型只能接受Pair<? extends Number>>。内部类型? extends Number 已经是协变的。您必须将封闭类型设为协变以允许协变。

Answer 4

我建议你看看documentation of generic wildcards，尤其是guidelines for wildcard use

坦率地说你的方法#doesntCompile

static void doesntCompile(Map<Integer, List<? extends Number>> map) {}

然后像打电话一样

doesntCompile(new HashMap<Integer, List<Integer>>());

根本不正确

让我们添加合法实施：

    static void doesntCompile(Map<Integer, List<? extends Number>> map) {
        List<Double> list = new ArrayList<>();
        list.add(0.);
        map.put(0, list);
    }

真的很好，因为Double扩展了Number，所以放List<Double>和List<Integer>一样绝对没问题，对吧？

但是，您仍然认为在您的示例中传递 new HashMap<Integer, List<Integer>>() 是合法吗？

编译器不这么认为，并且正在尽力避免这种情况。

尝试使用方法#compile 执行相同的实现，编译器显然不允许您将双精度列表放入映射中。

    static <T extends Number> void compiles(Map<Integer, List<T>> map) {
        List<Double> list = new ArrayList<>();
        list.add(10.);
        map.put(10, list); // does not compile
    }

基本上你只能放List<T>，这就是为什么用 new HashMap<Integer, List<Integer>>() 或 new HashMap<Integer, List<Double>>() 或 new HashMap<Integer, List<Long>>() 或 new HashMap<Integer, List<Number>>()。

因此，简而言之，您是在尝试使用编译器作弊，它可以公平地防御这种作弊。

注意：Maurice Perry 发布的答案绝对正确。我只是不确定它是否足够清楚，所以尝试（真的希望我设法）添加更广泛的帖子。