JDK 5.0中的泛型类型学习。

 

　　JDK 5.0 中增加的泛型类型，是 Java 语言中类型安全的一次重要改进。但是，对于初次使用泛型类型的用户来说，泛型的某些方面看起来可能不容易明白，甚至非常奇怪。在本月的“Java 理论和实践”中，Brian Goetz 分析了束缚第一次使用泛型的用户的常见陷阱。您可以通过讨论论坛与作者和其他读者分享您对本文的看法。（也可以单击本文顶端或底端的讨论来访问这个论坛。）

　　表面上看起来，无论语法还是应用的环境（比如容器类），泛型类型（或者泛型）都类似于 C++ 中的模板。但是这种相似性仅限于表面，Java 语言中的泛型基本上完全在编译器中实现，由编译器执行类型检查和类型推断，然后生成普通的非泛型的字节码。这种实现技术称为擦除（erasure）（编译器使用泛型类型信息保证类型安全，然后在生成字节码之前将其清除），这项技术有一些奇怪，并且有时会带来一些令人迷惑的后果。虽然范型是 Java 类走向类型安全的一大步，但是在学习使用泛型的过程中几乎肯定会遇到头痛（有时候让人无法忍受）的问题。

　　注意：本文假设您对 JDK 5.0 中的范型有基本的了解。

　　泛型不是协变的

　　虽然将集合看作是数组的抽象会有所帮助，但是数组还有一些集合不具备的特殊性质。Java 语言中的数组是协变的（covariant），也就是说，如果 Integer 扩展了 Number（事实也是如此），那么不仅 Integer 是 Number，而且 Integer[] 也是 Number[]，在要求 Number[] 的地方完全可以传递或者赋予 Integer[]。（更正式地说，如果 Number 是 Integer 的超类型，那么 Number[] 也是 Integer[] 的超类型）。您也许认为这一原理同样适用于泛型类型 —— List 是 List 的超类型，那么可以在需要 List 的地方传递 List。不幸的是，情况并非如此。

　　不允许这样做有一个很充分的理由：这样做将破坏要提供的类型安全泛型。如果能够将 List 赋给 List。那么下面的代码就允许将非 Integer 的内容放入 List：

　　List li = new ArrayList();

　　List ln = li; // illegal

　　ln.add(new Float(3.1415));

　　因为 ln 是 List，所以向其添加 Float 似乎是完全合法的。但是如果 ln 是 li 的别名，那么这就破坏了蕴含在 li 定义中的类型安全承诺 —— 它是一个整数列表，这就是泛型类型不能协变的原因。

　　其他的协变问题

　　数组能够协变而泛型不能协变的另一个后果是，不能实例化泛型类型的数组（new List[3] 是不合法的），除非类型参数是一个未绑定的通配符（new List[3] 是合法的）。让我们看看如果允许声明泛型类型数组会造成什么后果：

　　List[] lsa = new List[10]; // illegal

　　Object[] oa = lsa;  // OK because List is a subtype of Object

　　List li = new ArrayList();

　　li.add(new Integer(3));

　　oa[0] = li;

　　String s = lsa[0].get(0);

　　最后一行将抛出 ClassCastException，因为这样将把 List 填入本应是 List 的位置。因为数组协变会破坏泛型的类型安全，所以不允许实例化泛型类型的数组（除非类型参数是未绑定的通配符，比如 List）。

　　构造延迟

　　因为可以擦除功能，所以 List 和 List 是同一个类，编译器在编译 List 时只生成一个类（和 C++ 不同）。因此，在编译 List 类时，编译器不知道 V 所表示的类型，所以它就不能像知道类所表示的具体类型那样处理 List 类定义中的类型参数（List 中的 V）。

　　因为运行时不能区分 List 和 List（运行时都是 List），用泛型类型参数标识类型的变量的构造就成了问题。运行时缺乏类型信息，这给泛型容器类和希望创建保护性副本的泛型类提出了难题。

　　比如泛型类 Foo：

　　class Foo {

　　public void doSomething(T param) { ... }

　　}

　　在这里可以看到一种模式 —— 与泛型有关的很多问题或者折衷并非来自泛型本身，而是保持和已有代码兼容的要求带来的副作用。

　　泛化已有的类

　　在转化现有的库类来使用泛型方面没有多少技巧，但与平常的情况相同，向后兼容性不会凭空而来。我已经讨论了两个例子，其中向后兼容性限制了类库的泛化。

　　另一种不同的泛化方法可能不存在向后兼容问题，这就是 Collections.toArray(Object[])。传入 toArray() 的数组有两个目的 —— 如果集合足够小，那么可以将其内容直接放在提供的数组中。否则，利用反射（reflection）创建相同类型的新数组来接受结果。如果从头开始重写 Collections 框架，那么很可能传递给 Collections.toArray() 的参数不是一个数组，而是一个类文字：

　　interface Collection {

　　public T[] toArray(Class elementClass);

　　}

　　因为 Collections 框架作为良好类设计的例子被广泛效仿，但是它的设计受到向后兼容性约束，所以这些地方值得您注意，不要盲目效仿。

　　首先，常常被混淆的泛型 Collections API 的一个重要方面是 containsAll()、removeAll() 和 retainAll() 的签名。您可能认为 remove() 和 removeAll() 的签名应该是：

　　interface Collection {

　　public boolean remove(E e);  // not really

　　public void removeAll(Collection c);  // not really

　　}

　　但实际上却是：

　　interface Collection {

　　public boolean remove(Object o);

　　public void removeAll(Collection c);

　　}

　　为什么呢？答案同样是因为向后兼容性。x.remove(o) 的接口表明“如果 o 包含在 x 中，则删除它，否则什么也不做。”如果 x 是一个泛型集合，那么 o 不一定与 x 的类型参数兼容。如果 removeAll() 被泛化为只有类型兼容时才能调用（Collection），那么在泛化之前，合法的代码序列就会变得不合法，比如：

　　// a collection of Integers

　　Collection c = new HashSet();

　　// a collection of Objects

　　Collection r = new HashSet();

　　c.removeAll(r);

　　如果上述片段用直观的方法泛化（将 c 设为 Collection，r 设为 Collection