JDK5-0中的泛型类型学习

JDK5.0中的泛型类型学习核心提示：JDK5.0中增加的泛型类型，是Java语言中类型安全的一次重要改进。JDK5.0中增加的泛型类型，是Java语言中类型安全的一次重要改进。但是，对于初次使用泛型类型的用户来说，泛型的某些方面看起来可能不容易明白，甚至非常奇怪。在本月的“Java理论和实践”中，BrianGoetz分析了束缚第一次使用泛型的用户的常见陷阱。您可以通过讨论论坛与作者和其他读者分享您对本文的看法。（也可以单击本文顶端或底端的讨论来访问这个论坛。）表面上看起来，无论语法还是应用的环境（比如容器类），泛型类型（或者泛型）都类似于C++中的模板。但是这种相似性仅限于表面，Java语言中的泛型基本上完全在编译器中实现，由编译器执行类型检查和类型推断，然后生成普通的非泛型的字节码。这种实现技术称为擦除（erasure）（编译器使用泛型类型信息保证类型安全，然后在生成字节码之前将其清除），这项技术有一些奇怪，并且有时会带来一些令人迷惑的后果。虽然范型是Java类走向类型安全的一大步，但是在学习使用泛型的过程中几乎肯定会遇到头痛（有时候让人无法忍受）的问题。注意：本文假设您对JDK5.0中的范型有基本的了解。泛型不是协变的虽然将集合看作是数组的抽象会有所帮助，但是数组还有一些集合不具备的特殊性质。Java语言中的数组是协变的（covariant），也就是说，如果Integer扩展了Number（事实也是如此），那么不仅Integer是Number，而且Integer[]也是Number[]，在要求Number[]的地方完全可以传递或者赋予Integer[]。（更正式地说，如果Number是Integer的超类型，那么Number[]也是Integer[]的超类型）。您也许认为这一原理同样适用于泛型类型——ListNumber是ListInteger的超类型，那么可以在需要ListNumber的地方传递ListInteger。不幸的是，情况并非如此。不允许这样做有一个很充分的理由：这样做将破坏要提供的类型安全泛型。如果能够将ListInteger赋给ListNumber。那么下面的代码就允许将非Integer的内容放入ListInteger：ListIntegerli=newArrayListInteger();ListNumberln=li;//illegalln.add(newFloat(3.1415));因为ln是ListNumber，所以向其添加Float似乎是完全合法的。但是如果ln是li的别名，那么这就破坏了蕴含在li定义中的类型安全承诺——它是一个整数列表，这就是泛型类型不能协变的原因。其他的协变问题数组能够协变而泛型不能协变的另一个后果是，不能实例化泛型类型的数组（newListString[3]是不合法的），除非类型参数是一个未绑定的通配符（newList?[3]是合法的）。让我们看看如果允许声明泛型类型数组会造成什么后果：ListString[]lsa=newListString[10];//illegalObject[]oa=lsa;//OKbecauseListStringisasubtypeofObjectListIntegerli=newArrayListInteger();li.add(newInteger(3));oa[0]=li;Strings=lsa[0].get(0);最后一行将抛出ClassCastException，因为这样将把ListInteger填入本应是ListString的位置。因为数组协变会破坏泛型的类型安全，所以不允许实例化泛型类型的数组（除非类型参数是未绑定的通配符，比如List?）。构造延迟因为可以擦除功能，所以ListInteger和ListString是同一个类，编译器在编译ListV时只生成一个类（和C++不同）。因此，在编译ListV类时，编译器不知道V所表示的类型，所以它就不能像知道类所表示的具体类型那样处理ListV类定义中的类型参数（ListV中的V）。因为运行时不能区分ListString和ListInteger（运行时都是List），用泛型类型参数标识类型的变量的构造就成了问题。运行时缺乏类型信息，这给泛型容器类和希望创建保护性副本的泛型类提出了难题。比如泛型类Foo：classFooT{publicvoiddoSomething(Tparam){...}}在这里可以看到一种模式——与泛型有关的很多问题或者折衷并非来自泛型本身，而是保持和已有代码兼容的要求带来的副作用。泛化已有的类在转化现有的库类来使用泛型方面没有多少技巧，但与平常的情况相同，向后兼容性不会凭空而来。我已经讨论了两个例子，其中向后兼容性限制了类库的泛化。另一种不同的泛化方法可能不存在向后兼容问题，这就是Collections.toArray(Object[])。传入toArray()的数组有两个目的——如果集合足够小，那么可以将其内容直接放在提供的数组中。否则，利用反射（reflection）创建相同类型的新数组来接受结果。如果从头开始重写Collections框架，那么很可能传递给Collections.toArray()的参数不是一个数组，而是一个类文字：interfaceCollectionE{publicT[]toArray(ClassTsuperEelementClass);}因为Collections框架作为良好类设计的例子被广泛效仿，但是它的设计受到向后兼容性约束，所以这些地方值得您注意，不要盲目效仿。首先，常常被混淆的泛型CollectionsAPI的一个重要方面是containsAll()、removeAll()和retainAll()的签名。您可能认为remove()和removeAll()的签名应该是：interfaceCollectionE{publicbooleanremove(Ee);//notreallypublicvoidremoveAll(Collection?extendsEc);//notreally}但实际上却是：interfaceCollectionE{publicbooleanremove(Objecto);publicvoidremoveAll(Collection?c);}为什么呢？答案同样是因为向后兼容性。x.remove(o)的接口表明“如果o包含在x中，则删除它，否则什么也不做。”如果x是一个泛型集合，那么o不一定与x的类型参数兼容。如果removeAll()被泛化为只有类型兼容时才能调用（Collection?extendsE），那么在泛化之前，合法的代码序列就会变得不合法，比如：//acollectionofIntegersCollectionc=newHashSet();//acollectionofObjectsCollectionr=newHashSet();c.removeAll(r);如果上述片段用直观的方法泛化（将c设为CollectionInteger，r设为CollectionObject），如果removeAll()的签名要求其参数为Collection?extendsE而不是no-op，那么就无法编译上面的代码。泛型类库的一个主要目标就是不打破或者改变已有代码的语义，因此，必须用比从头重新设计泛型所使用类型约束更弱的类型约束来定义remove()、removeAll()、retainAll()和containsAll()。在泛型之前设计的类可能阻碍了“显然的”泛型化方法。这种情况下就要像上例这样进行折衷，但是如果从头设计新的泛型类，理解Java类库中的哪些东西是向后兼容的结果很有意义，这样可以避免不适当的模仿。擦除的实现因为泛型基本上都是在Java编译器中而不是运行库中实现的，所以在生成字节码的时候，差不多所有关于泛型类型的类型信息都被“擦掉”了。换句话说，编译器生成的代码与您手工编写的不用泛型、检查程序的类型安全后进行强制类型转换所得到的代码基本相同。与C++不同，ListInteger和ListString是同一个类（虽然是不同的类型但都是List?的子类型，与以前的版本相比，在JDK5.0中这是一个更重要的区别）。擦除意味着一个类不能同时实现ComparableString和ComparableNumber，因为事实上两者都在同一个接口中，指定同一个compareTo()方法。声明DecimalString类以便与String与Number比较似乎是明智的，但对于Java编译器来说，这相当于对同一个方法进行了两次声明：publicclassDecimalStringimplementsComparableNumber,ComparableString{...}//nope擦除的另一个后果是，对泛型类型参数是用强制类型转换或者instanceof毫无意义。下面的代码完全不会改善代码的类型安全性：publicTTnaiveCast(Tt,Objecto){return(T)o;}编译器仅仅发出一个类型未检查转换警告，因为它不知道这种转换是否安全。naiveCast()方法实际上根本不作任何转换，T直接被替换为Object，与期望的相反，传入的对象被强制转换为Object。擦除也是造成上述构造问题的原因，即不能创建泛型类型的对象，因为编译器不知道要调用什么构造函数。如果泛型类需要构造用泛型类型参数来指定类型的对象，那么构造函数应该接受类文字（Foo.class）并将它们保存起来，以便通过反射创建实例。结束语泛型是Java语言走向类型安全的一大步，但是泛型设施的设计和类库的泛化并非未经过妥协。扩展虚拟机指令集来支持泛型被认为是无法接受的，因为这会为Java厂商升级其JVM造成难以逾越的障碍。因此采用了可以完全在编译器中实现的擦除方法。类似地，在泛型Java类库时，保持向后兼容也为类库的泛化方式设置了很多限制，产生了一些混乱的、令人沮丧的结构（如Array.newInstance()）。这并非泛型本身的问题，而是与语言的演化与兼容有关。但这些也使得泛型学习和应用起来更让人迷惑，更加困难。原文出处：中软卓越