Java 理论和实践: 了解泛型

简介: JDK 5.0 中增长的泛型类型,是 Java 语言中类型安全的一次重要改进。可是,对于初次使用泛型类型的用户来讲,泛型的某些方面看起来可能不容易明白,甚至很是奇怪。在本月的“Java 理论和实践”中,Brian Goetz 分析了束缚第一次使用泛型的用户的常见陷阱。您能够经过 讨论论坛与做者和其余读者分享您对本文的见解。(也能够单击本文顶端或底端的 讨论来访问这个论坛。) html

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

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

泛型不是协变的 安全

虽然将集合看做是数组的抽象会有所帮助,可是数组还有一些集合不具有的特殊性质。Java 语言中的数组是协变的(covariant),也就是说,若是 Integer扩展了 Number(事实也是如此),那么不只 Integer是 Number,并且 Integer[]也是 Number[],在要求Number[]的地方彻底能够传递或者赋予 Integer[]。(更正式地说,若是 Number是 Integer的超类型,那么 Number[]也是Integer[]的超类型)。您也许认为这一原理一样适用于泛型类型 —— List<Number>是 List<Integer>的超类型,那么能够在须要List<Number>的地方传递 List<Integer>。不幸的是,状况并不是如此。 架构

不容许这样作有一个很充分的理由:这样作将破坏要提供的类型安全泛型。若是可以将 List<Integer>赋给 List<Number>。那么下面的代码就容许将非 Integer的内容放入 List<Integer>: 框架

List<Integer> li = new ArrayList<Integer>(); 
 List<Number> ln = li; // illegal 
 ln.add(new Float(3.1415));

由于 ln是 List<Number>,因此向其添加 Float彷佛是彻底合法的。可是若是 ln是 li的别名,那么这就破坏了蕴含在 li定义中的类型安全承诺 —— 它是一个整数列表,这就是泛型类型不能协变的缘由。 jsp

其余的协变问题 函数

数组可以协变而泛型不能协变的另外一个后果是,不能实例化泛型类型的数组(new List<String>[3]是不合法的),除非类型参数是一个未绑定的通配符(new List<?>[3]是合法的)。让咱们看看若是容许声明泛型类型数组会形成什么后果: 学习

List<String>[] lsa = new List<String>[10]; // illegal 
 Object[] oa = lsa;  // OK because List<String> is a subtype of Object 
 List<Integer> li = new ArrayList<Integer>(); 
 li.add(new Integer(3)); 
 oa[0] = li; 
 String s = lsa[0].get(0);

最后一行将抛出 ClassCastException,由于这样将把 List<Integer>填入本应是 List<String>的位置。由于数组协变会破坏泛型的类型安全,因此不容许实例化泛型类型的数组(除非类型参数是未绑定的通配符,好比 List<?>)。 ui

回页首

构造延迟

由于能够擦除功能,因此 List<Integer>和 List<String>是同一个类,编译器在编译 List<V>时只生成一个类(和 C++ 不一样)。所以,在编译 List<V>类时,编译器不知道 V所表示的类型,因此它就不能像知道类所表示的具体类型那样处理 List<V>类定义中的类型参数(List<V>中的 V)。

由于运行时不能区分 List<String>和 List<Integer>(运行时都是 List),用泛型类型参数标识类型的变量的构造就成了问题。运行时缺少类型信息,这给泛型容器类和但愿建立保护性副本的泛型类提出了难题。

好比泛型类 Foo:

class Foo<T> { 
  public void doSomething(T param) { ... } 
 }

假设 doSomething()方法但愿复制输入的 param参数,会怎么样呢?没有多少选择。您可能但愿按如下方式实现 doSomething():

public void doSomething(T param) { 
  T copy = new T(param);  // illegal 
 }

可是您不能使用类型参数访问构造函数,由于在编译的时候还不知道要构造什么类,所以也就不知道使用什么构造函数。使用泛型不能表达“T必须拥有一个拷贝构造函数(copy constructor)”(甚至一个无参数的构造函数)这类约束,所以不能使用泛型类型参数所表示的类的构造函数。

clone()怎么样呢?假设在 Foo的定义中,T扩展了 Cloneable:

class Foo<T extends Cloneable> { 
  public void doSomething(T param) { 
    T copy = (T) param.clone();  // illegal 
  } 
 }

不幸的是,仍然不能调用 param.clone()。为何呢?由于 clone()在 Object中是保护访问的,调用 clone()必须经过将 clone()改写公共访问的类引用来完成。可是从新声明 clone()为 public 并不知道 T,所以克隆也无济于事。

构造通配符引用

所以,不能复制在编译时根本不知道是什么类的类型引用。那么使用通配符类型怎么样?假设要建立类型为 Set<?>的参数的保护性副本。您知道 Set有一个拷贝构造函数。并且别人可能曾经告诉过您,若是不知道要设置的内容的类型,最好使用 Set<?>代替原始类型的 Set,由于这种方法引发的未检查类型转换警告更少。因而,能够试着这样写:

class Foo { 
  public void doSomething(Set<?> set) { 
    Set<?> copy = new HashSet<?>(set);  // illegal 
  } 
 }

不幸的是,您不能用通配符类型的参数调用泛型构造函数,即便知道存在这样的构造函数也不行。不过您能够这样作:

class Foo { 
  public void doSomething(Set<?> set) { 
    Set<?> copy = new HashSet<Object>(set);  
  } 
 }

这种构造不那么直观,但它是类型安全的,并且能够像 new HashSet<?>(set)那样工做。

构造数组

如何实现 ArrayList<V>?假设类 ArrayList管理一个 V数组,您可能但愿用 ArrayList<V>的构造函数建立一个 V数组:

class ArrayList<V> { 
  private V[] backingArray; 
  public ArrayList() { 
    backingArray = new V[DEFAULT_SIZE]; // illegal 
  } 
 }

可是这段代码不能工做 —— 不能实例化用类型参数表示的类型数组。编译器不知道 V到底表示什么类型,所以不能实例化 V数组。

Collections 类经过一种别扭的方法绕过了这个问题,在 Collections 类编译时会产生类型未检查转换的警告。ArrayList具体实现的构造函数以下:

class ArrayList<V> { 
  private V[] backingArray; 
  public ArrayList() { 
    backingArray = (V[]) new Object[DEFAULT_SIZE]; 
  } 
 }

为什么这些代码在访问 backingArray时没有产生 ArrayStoreException呢?不管如何,都不能将 Object数组赋给 String数组。由于泛型是经过擦除实现的,backingArray的类型实际上就是 Object[],由于 Object代替了 V。这意味着:实际上这个类指望backingArray是一个 Object数组,可是编译器要进行额外的类型检查,以确保它包含 V类型的对象。因此这种方法很奏效,可是很是别扭,所以不值得效仿(甚至连泛型 Collections 框架的做者都这么说,请参阅 参考资料)。

还有一种方法就是声明 backingArray为 Object数组,并在使用它的各个地方强制将它转化为 V[]。仍然会看到类型未检查转换警告(与上一种方法同样),可是它使一些未明确的假设更清楚了(好比 backingArray不该逃避 ArrayList的实现)。

其余方法

最好的办法是向构造函数传递类文字(Foo.class),这样,该实现就能在运行时知道 T的值。不采用这种方法的缘由在于向后兼容性 —— 新的泛型集合类不能与 Collections 框架之前的版本兼容。

下面的代码中 ArrayList采用了如下方法:

public class ArrayList<V> implements List<V> { 
  private V[] backingArray; 
  private Class<V> elementType; 
  public ArrayList(Class<V> elementType) { 
    this.elementType = elementType; 
    backingArray = (V[]) Array.newInstance(elementType, DEFAULT_LENGTH); 
  } 
 }

可是等一等!仍然有不妥的地方,调用 Array.newInstance()时会引发未经检查的类型转换。为何呢?一样是因为向后兼容性。Array.newInstance()的签名是:

public static Object newInstance(Class<?> componentType, int length)

而不是类型安全的:

public static<T> T[] newInstance(Class<T> componentType, int length)

为什么 Array用这种方式进行泛化呢?一样是为了保持向后兼容。要建立基本类型的数组,如 int[],可使用适当的包装器类中的TYPE字段调用 Array.newInstance()(对于 int,能够传递 Integer.TYPE做为类文字)。用 Class<T>参数而不是 Class<?>泛化Array.newInstance(),对于引用类型有更好的类型安全,可是就不能使用 Array.newInstance()建立基本类型数组的实例了。也许未来会为引用类型提供新的 newInstance()版本,这样就二者兼顾了。

在这里能够看到一种模式 —— 与泛型有关的不少问题或者折衷并不是来自泛型自己,而是保持和已有代码兼容的要求带来的反作用。


泛化已有的类

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

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

interface Collection<E> { 
  public T[] toArray(Class<T super E> elementClass); 
 }

由于 Collections 框架做为良好类设计的例子被普遍效仿,可是它的设计受到向后兼容性约束,因此这些地方值得您注意,不要盲目效仿。

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

interface Collection<E> { 
  public boolean remove(E e);  // not really 
  public void removeAll(Collection<? extends E> c);  // not really 
 }

但实际上倒是:

interface Collection<E> { 
  public boolean remove(Object o);  
  public void removeAll(Collection<?> c); 
 }

为何呢?答案一样是由于向后兼容性。x.remove(o)的接口代表“若是 o包含在 x中,则删除它,不然什么也不作。”若是 x是一个泛型集合,那么 o不必定与 x的类型参数兼容。若是 removeAll()被泛化为只有类型兼容时才能调用(Collection<? extends E>),那么在泛化以前,合法的代码序列就会变得不合法,好比:

// a collection of Integers 
 Collection c = new HashSet(); 
 // a collection of Objects 
 Collection r = new HashSet(); 
 c.removeAll(r);

若是上述片断用直观的方法泛化(将 c设为 Collection<Integer>,r设为 Collection<Object>),若是 removeAll()的签名要求其参数为 Collection<? extends E>而不是 no-op,那么就没法编译上面的代码。泛型类库的一个主要目标就是不打破或者改变已有代码的语义,所以,必须用比从头从新设计泛型所使用类型约束更弱的类型约束来定义 remove()、removeAll()、retainAll()和containsAll()。

在泛型以前设计的类可能阻碍了“显然的”泛型化方法。这种状况下就要像上例这样进行折衷,可是若是从头设计新的泛型类,理解 Java 类库中的哪些东西是向后兼容的结果颇有意义,这样能够避免不适当的模仿。


擦除的实现

由于泛型基本上都是在 Java 编译器中而不是运行库中实现的,因此在生成字节码的时候,差很少全部关于泛型类型的类型信息都被“擦掉”了。换句话说,编译器生成的代码与您手工编写的不用泛型、检查程序的类型安全后进行强制类型转换所获得的代码基本相同。与 C++ 不一样,List<Integer>和 List<String>是同一个类(虽然是不一样的类型但都是 List<?>的子类型,与之前的版本相比,在 JDK 5.0 中这是一个更重要的区别)。

擦除意味着一个类不能同时实现 Comparable<String>和 Comparable<Number>,由于事实上二者都在同一个接口中,指定同一个compareTo()方法。声明 DecimalString类以便与 String与 Number比较彷佛是明智的,但对于 Java 编译器来讲,这至关于对同一个方法进行了两次声明:

public class DecimalString implements Comparable<Number>, Comparable<String>
{ ... } // nope

擦除的另外一个后果是,对泛型类型参数是用强制类型转换或者 instanceof毫无心义。下面的代码彻底不会改善代码的类型安全性:

public <T> T naiveCast(T t, Object o) { return (T) o; }

编译器仅仅发出一个类型未检查转换警告,由于它不知道这种转换是否安全。naiveCast()方法实际上根本不做任何转换,T直接被替换为 Object,与指望的相反,传入的对象被强制转换为 Object。

擦除也是形成上述构造问题的缘由,即不能建立泛型类型的对象,由于编译器不知道要调用什么构造函数。若是泛型类须要构造用泛型类型参数来指定类型的对象,那么构造函数应该接受类文字(Foo.class)并将它们保存起来,以便经过反射建立实例。

回页首

结束语

泛型是 Java 语言走向类型安全的一大步,可是泛型设施的设计和类库的泛化并不是未通过妥协。扩展虚拟机指令集来支持泛型被认为是没法接受的,由于这会为 Java 厂商升级其 JVM 形成难以逾越的障碍。所以采用了能够彻底在编译器中实现的擦除方法。相似地,在泛型 Java 类库时,保持向后兼容也为类库的泛化方式设置了不少限制,产生了一些混乱的、使人沮丧的结构(如Array.newInstance())。这并不是泛型自己的问题,而是与语言的演化与兼容有关。但这些也使得泛型学习和应用起来更让人迷惑,更加困难。


参考资料

关于做者

Brian Goetz 有超过 17 年的专业软件开发经验。他是 Quiotix 的首席顾问,这是一家位于加利福尼亚 Los Altos 的软件开发和咨询公司,他还参加了多个 JCP Expert Groups。请参阅 Brian 在主流专业出版物上已经发表或即将发表的文章

相关文章
相关标签/搜索