最近关心了一下J2SE5.0的泛型，以在下不成熟不全面的眼光来看，Tiger引入的泛型机制显得有些“鸡肋”。本身就是单根继承Object设计的Java，引入这个泛型，在代码背后还是变成了Object。感觉多少有点意义不大。
相对于C++的泛型机制来看，Java此作更是有点“形式主义”的味道，作用不大，且徒增了一些麻烦；但终于Java现在还是能称它支持泛型了。不过至于是不是真的这么“鸡肋”，持续关注中。
不知道大家如何看待这个东西呢。
先看看C++泛型是如何实现的。在C++中，我们知道，如果一但有一个模板类的参数化实例，则会生成一个相应给定了模板参数的类，不知道这样说是不是够清楚。也就是说，如果有一个C++的类这样：
template<class elemtype>class linklist
{
private:
node<elemtype> *head;
....
}
那么，当实现两种linklist如，linklist<String>，linklist<int>的实例时，则会有两个linklist的版本。也就是说，C++编译器会根据同一份代码，在在编译时根据传入的不同类型（String，int，...）来生成不同的类，最后生成目标文件。一般称C++这种泛型的实现方法是“膨胀法”。
从JDK1.3起，Java编程都可能以编译器外挂附件的方式支持泛型的语法。在JDK1.3，可以配合GJ（GenericJava)——这样一个支持Java泛型的补充件来进行。随后，泛型议题正式成为JSR#14，最终在JDK1.5中得以正式出现。
在Java方面，定义泛型类大致像这样：
class linklist<T>{
private:
T node;
...
};
相对C++，Java使用了完全不同的机制，被称为“擦除法”。规则大致是这样的：
1.一个参数化的类型经过擦拭后，应该去除其参数。上例中，linklist<T>变成了linklist。
2.一个未被参数化的类型，经过擦拭后应该获得类型本身。比如Byte，经擦拭后仍为Byte。
3.一个类型参数经过擦拭后的结果为Object。上例中，T被擦拭为Object。
4.如果某个method call的回传类型是个类型参数，编译器会为它安插适当的转型动作。
所以，就像我最上一楼讲的，具有单根继承体系的Java，本来所有的Java class都继承自java.lang.Object，因此，任何一种Java Object都可以被放进各种容器中，换句话说，Java容器本来就是一种“泛型的异质”容器。
但现在加上参数化，反而是将它“窄化”了，不过，也正是这样，让编译器得以在编译过程中帮助我们进行类型检查。
然后，我感觉对于Java来说，泛型更像一种形式，如果取消这一种“尖括号面具”，Java其实仍然是能正常的应对。因此，我讲其是“鸡肋”，就是感觉有它能做，无它也能做。而泛型之于Java，是在牺牲了更多Java编写简便性的同时，做到了编译时类型检查——不过，泛型的重点却不于此。如果Java仅是这样(我想当然不止如此)而引入泛型，岂不显得不值？
