快捷搜索:

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) { ... }

}

假设 doSomething() 措施盼望复制输入的 param 参数,会怎么样呢?没有若干选择。您可能盼望按以下要领实现 doSomething():

public void doSomething(T param) {

T copy = new T(param);// illegal

}

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

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

class Foo {

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(set);

}

}

这种构造不那么直不雅,但它是类型安然的,而且可以像 new HashSet(set) 那样事情。

构造数组

若何实现 ArrayList?假设类 ArrayList 治理一个 V 数组,您可能盼望用 ArrayList 的构造函数创建一个 V 数组:

class ArrayList {

private V[] backingArray;

public ArrayList() {

backingArray = new V[DEFAULT_SIZE]; // illegal

}

}

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

Collections 类经由过程一类别扭的措施绕过了这个问题,在 Collections 类编译时会孕育发生类型未反省转换的警告。ArrayList 详细实现的构造函数如下:

class ArrayList {

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 implements List {

private V[] backingArray;

private Class elementType;

public ArrayList(Class 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[] newInstance(Class componentType, int length)

为何 Array 用这种要领进行泛化呢?同样是为了维持向后兼容。要创建基础类型的数组,如 int[],可以应用适当的包装器类中的 TYPE 字段调用 Array.newInstance()(对付 int,可以通报 Integer.TYPE 作为类翰墨)。用 Class 参数而不是 Class 泛化 Array.newInstance(),对付引用类型有更好的类型安然,然则就不能应用 Array.newInstance() 创建基础类型数组的实例了。大概将来会为引用类型供给新的 newInstance() 版本,这样就两者兼顾了。

在这里可以看到一种模式 —— 与泛型有关的很多问题或者协调并非来自泛型本身,而是维持和已有代码兼容的要求带来的副感化。

泛化已有的类

在转化现有的库类来应用泛型方面没有若干技术,但与寻常的环境相同,向后兼容性不会凭空而来。我已经评论争论了两个例子,此中向后兼容性限定了类库的泛化。

另一种不合的泛化措施可能不存在向后兼容问题,这便是 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),假如 removeAll() 的署名要求其参数为 Collection 而不是 no-op,那么就无法编译上面的代码。泛型类库的一个主要目标便是不突破或者改变已有代码的语义,是以,必须用比从头从新设计泛型所应用类型约束更弱的类型约束来定义 remove()、removeAll()、retainAll() 和 containsAll()。

在泛型之前设计的类可能阻碍了“显然的”泛型化措施。这种环境下就要像上例这样进行协调,然则假如从头设计新的泛型类,理解 Java 类库中的哪些器械是向后兼容的结果很故意义,这样可以避免不适当的仿照。

擦除的实现

由于泛型基础上都是在 Java 编译器中而不是运行库中实现的,以是在天生字节码的时刻,差不多所有关于泛型类型的类型信息都被“擦掉落”了。换句话说,编译器天生的代码与您手工编写的不用泛型、反省法度榜样的类型安然落后行强制类型转换所获得的代码基真相同。与 C++ 不合,List 和 List 是同一个类(虽然是不合的类型但都是 List 的子类型,与曩昔的版真相比,在 JDK 5.0 中这是一个更紧张的差别)。

擦除意味着一个类不能同时实现 Comparable 和 Comparable,由于事实上两者都在同一个接口中,指定同一个 compareTo() 措施。声明 DecimalString 类以便与 String 与 Number 对照彷佛是明智的,但对付 Java 编译器来说,这相称于对同一个措施进行了两次声明:

public class DecimalString implements Comparable, Comparable { ... } // nope

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

publicT naiveCast(T t, Object o) { return (T) o; }

编译器仅仅发出一个类型未反省转换警告,由于它不知道这种转换是否安然。naiveCast() 措施实际上根本不作任何转换,T 直接被调换为 Object,与期望的相反,传入的工具被强制转换为 Object。

擦除也是造成上述构造问题的缘故原由,即不能创建泛型类型的工具,由于编译器不知道要调用什么构造函数。假如泛型类必要构造用泛型类型参数来指定类型的工具,那么构造函数应该吸收类翰墨(Foo.class)并将它们保存起来,以便经由过程反射创建实例。

停止语

泛型是 Java 说话走向类型安然的一大年夜步,然则泛型举措措施的设计和类库的泛化并非未颠末退让。扩展虚拟机指令集来支持泛型被觉得是无法吸收的,由于这会为 Java 厂商进级其 JVM 造成难以超越的障碍。是以采纳了可以完全在编译器中实现的擦除措施。类似地,在泛型 Java 类库时,维持向后兼容也为类库的泛化要领设置了很多限定,孕育发生了一些纷乱的、令人沮丧的布局(如 Array.newInstance())。这并非泛型本身的问题,而是与说话的演化与兼容有关。但这些也使得泛型进修和利用起来更让人迷惑,加倍艰苦。

您可能还会对下面的文章感兴趣: