泛型通配符

通配符

首先，要展示数组的一种特殊行为，可以向导出类型的数组赋予基类型的数组引用。

class Fruit {
}

class Apple extends Fruit {
}

class Jonathan extends Apple {
}

class Orange extends Fruit {
}

public class CovariantArrays {
    public static void main(String[] args) {
        Fruit[] fruits = new Apple[10];
        fruits[0] = new Apple();
        fruits[1] = new Jonathan();
        try {
            fruits[0] = new Fruit();
        } catch (Exception e) {
            System.out.println(e);
        }
        try {
            fruits[0] = new Orange();
        } catch (Exception e) {
            System.out.println(e);
        }
    }
}

// Outputs
java.lang.ArrayStoreException: com.daidaijie.generices.holder.Fruit
java.lang.ArrayStoreException: com.daidaijie.generices.holder.Orange

main()的第一行创建了一个Apple数组，并将其赋值给一个Fruit数组引用。这是有意义的，因为Apple也是一种Fruit，所以Apple数组应该也是一个Fruit数组。
但是,如果实际的数组类型是Apple[]，你应该只能在其中放置Apple或者Apple的子类型，这在编译期和运行时都可以工作。但是要注意的是，编译器允许Fruit放置到这个数组中，这对于编译器来说是有意义的，因为它有一个Fruit引用——它有什么理由不允许将这个Fruit对象或者任意从Fruit继承出来的对象(例如Orange)放置到这个数组中呢？因此在编译期，这是允许的。但是，运行时数组机制知道它是Apple，因此会在向数组中放置异构类型时抛出异常。
实际上，向上转型并不合适用在这里。这里真正做的是将一个数组赋值为另一个数组。数组的行为应该是它可以持有其他对象，这里只是因为我们能够向上转型而已，所以很明显，数组对象可以保留有关它们包含的对象类型的规则。就好像数组对它们持有的对象是有意识的，因为在编译期检查和运行时检查之间，你不能滥用它们。
对数组的这种赋值并不是那么可怕，因为在运行时可以发现你已经插入不正确的类型，但是泛型的主要目的是将这种错误检测能够移入到编译期。因此当试图使用泛型容器来代替数组的时候，会发生什么呢。

public class NonCovariantGenerics {
    // compile error
    List<Fruit> flist = new ArrayList<Apple>;
}

第一次看这段代码的时候会认为,"不能讲一个Apple容器赋值给一个Fruit容器"。但是，泛型不仅和容器相关正确的说法是，"不能把一个涉及Apple的泛型赋值给一个涉及Fruit的泛型"。如果就像在数组的情况一样，编译器对代码的了解足够多，就可以确定所涉及到的容器，，那么它可能会留下一些余地。但是它不知道任何有关这方面的信息，因此她拒绝向上转型。然而这根本不是向上转型——Apple的List不是Fruit的List。Apple的List将持有Apple的子类型，而Fruit将持有任何类型的Fruit,诚然，这包括Apple在内，但是它不是一个Apple的List，它仍旧是Fruit的List。Apple的List在类型上不等价于Fruit的List，即使Apple是一种Fruit类型。
而真正的问题是在谈论容器的类型，而不是容器持有的类型。与数组不同，泛型没有内建的协变类型。这是因为数组在语言中是完全定义的，因此内建了编译期和运行期的检查，但是在使用泛型时，编译器和运行时系统都不知道你想用类型干什么，以及应该采用什么样的规则。
但是有时候，想在两个类型之间建立某种向上转型的关系，这正是通配符允许的。

public class GenericsAndCovariance {
    public static void main(String[] args) {
        List<? extends Fruit> flist = new ArrayList<>();
        // flist.add(new Apple());
        // flist.add(new Fruit());
        // flist.add(new Object());
        flist.add(null); //合法但是没有意义
        // 我们至少知道这会返回Fruit类型
        Fruit f = flist.get(0);
    }
}

flist类型现在是List<? extends Fruit>，可以将其读作"具有任何从Fruit继承的类型的类型的列表"，但是这实际上并不意味着这个List将持有任何类型的Fruit。通配符引用的是明确的类型，一次它意味着"某种flist引用没有指定具体的类型"。因此这个被赋值的List必须持有诸如Fruit或者Apple这样的某种指定的类型，但是为了向上转型为flist，这个类型是什么没人关心。
如果唯一的限制是这个List要持有某种具体的Fruit或者Fruit的子类型，但是实际上并不关心它是什么，那么可以用这样的List做什么呢？如果不知道List要持有什么类型，那么怎么样才能向其中安全地添加对象呢，就像在CovariantArrays.java中向上转型数组一样，所以答案是不能，除非编译器而不是运行时系统可以阻止这种操作的发生，但是很快会发现这一问题。
现在事情有点极端了，因为不能向刚刚声明过将持有Apple对象的List放置一个Apple对象了。但是编译器并不知道这一点。List<？extends Fruit>可以合法地指向一个List<Orange>。因此一旦执行了这种类型的向上转型，就会丢失掉向其中传递任何对象的能力，就算是传递Object也不行。
但另一方面，如果调用的是一个返回Fruit的方法，则是安全的，因为这个List中任何的对象至少具有Fruit类型，因此编译器允许这样做。

“智能”的编译器

编译器不一定会阻止通配符修饰的泛型类中，调用任何接受参数的方法。

public class CompilerIntelligence {

    public static void main(String[] args) {
        List<? extends Fruit> flist = Arrays.asList(new Apple());
        Apple a = (Apple) flist.get(0); // no warning
        flist.contains(new Apple()); // args is 'Object'
        flist.indexOf(new Apple()); // args is 'Object'
    }
}

上面代码中，对contains()和indexOf()的调用，这两个方法都接受Apple对象作为参数，而这些调用都可以正常执行。这不是因为编译器会去检查代码，以查看特定的方法是否修改了某个对象，而是因为contains()和indexOf()将接受Object类型的参数。而add()却是接收了一个具有泛型参数类型的参数，因为当指定一个ArrayList<? extends Fruits>时，add()的参数就变成了？Extends Fruits，从这个描述中编译器并不能了解到这里需要Fruits的哪个具体子类型，因此它也不会接收任何类型的Fruit。即使是将Apple向上转型为Fruit，也无关紧要——编译器将直接拒绝对参数列表设计通配符的方法(例如add()的调用)。
在调用contains()和indexOf()时，参数类型是Object，因此不涉及任何通配符，而编译器也将允许这个调用。
所以这意味着，这将由泛型类的设计者来决定哪种调用是“安全的”，并使用Object作为其参数类型。而为了在类型中使用通配符的情况下禁止这类调用，我们需要在参数中使用类型参数。
可以在一个简单的Holder类中看到这一点。

public class Holder<T> {
    private T value;

    public Holder() {
    }

    public Holder(T value) {
        this.value = value;
    }

    public T get() {
        return value;
    }

    public void set(T value) {
        this.value = value;
    }

    @Override
    public boolean equals(Object obj) {
        return value.equals(obj);
    }

    public static void main(String[] args) {
        Holder<Apple> apple = new Holder<>(new Apple());
        Apple d = apple.get();

        // can't not upcast
        // Holder<Fruit> fruit = apple;
        Holder<? extends Fruit> fruit = apple; // Ok
        Fruit p = fruit.get();
        try {
            Orange c = (Orange) fruit.get();
        } catch (Exception e) {
            System.out.println(e);
            // fruit.set(new Apple()); Can't call set()
            // fruit.set(new Fruit); Can't call set()
            System.out.println(fruit.equals(d)); // Ok
        }
    }
}

// Outputs
java.lang.ClassCastException: com.daidaijie.generices.holder.Apple cannot be cast to com.daidaijie.generices.holder.Orange
true

Holder有一个接受T类型对象的set()方法，和一个get()方法，以及一个接受Object对象的equals()方法。
可以看到代码中，Holder<Apple>不能向上转型为Holder<Fruits>，但是可以向上转型为Holder<？ extends Fruits>。如果调用get()，它只会返回一个Fruit——这就是在给定“任何扩展自Fruit的对象”这一边界之后，它所能知道的一切。如果能够了解更多的信息，那么可以转型到某种具体的Fruit类型，而这不会调至任何的警告，但是存在得到ClassCastException的风险。set()方法不能工作于Apple或Fruit，因为set的参数也是“? extends Fruit”，这意味它可以是任何事物，而编译器无法验证“任何事物”的类型安全性。
但是，equals()方法工作良好，因为它将接受Object类型而并非T类型的参数。因此，编译器只关注传递进来和要返回的对象类型，它并不会分析代码，以查看是否执行了任何实际的写入和读取操作。