Effective Java笔记（26）请不要使用原生态类型
首先介绍一些术语 。 声明中具有一个或者多个类型参数（ type parameter ）的类或者接口，就是泛型（ generic ）类或者接口 。 例如，List 接口就只有单个类型参数 E ，表示列表的元素类型 。这个接口的全称是 List
每一种泛型定义一组参数化的类型（ parameterized type)，构成格式为 ： 先是类或者接口的名称，接着用尖括 号（＜＞） 把对应于泛型形式类型参数的实际类型参数列表括起来 。 例如，List< String> （读作 “字符串列表”）是一个参数化的类型，表示元素类型为 String 的列表 。（String 是与形式的类型参数 E 相对应的实际类型参数 。）
最后一点，每一种泛型都定义一个原生态类型（ raw type ），即不带任何实际类型参数的泛型名称 。 例如，与 List < E＞相对应的原生态类型是 List 。 原生态类型就像从类型声明中删除了所有泛型信息一样 。 它们的存在主要是为了与泛型出现之前的代码相兼容 。
在 Java 增加泛型之前，下面这个集合声明是值得参考的 。 从 Java 9 开始，它依然合法，但是已经没什么参考价值了：
private final Collection stamps = ...;
如果现在使用这条声明，并且不小心将一个 coin 放进了 stamp 集合中，这一错误的插入照样得以编译和运行，不会出错（不过编译器确实会发出一条模糊 的警告信息） ：
stamps.add(new Coin( ... ));直到从 stamp 集合中获取 co 工 n 时才会收到一条错误提示：
for (Iterator i = stamps.iterator(); i.hasNext(); )
Stamp stamp = (Stamp) i.next();
stamp.cancel() ;
出错之后应该尽快发现， 最好是编译时就发现。在本例中，直到运行时才发现错误，已经出错很久了，而且它在代码中所处的位置，距离包含错误的这部分代码已经很远了 。一旦发现ClassCastException ，就必须搜索代码，查找将coin 放进 stamp 集合的方法调用 。 此时编译器帮不上忙，因为它无法理解这种注释 ：“ Contains only Stamp instances ”（只包含 Stamp 实例）。
有了泛型之后，类型声 明中可以包含以下信息，而不是注释 ：
private final Collection stamps = ...; 通过这条声明，编译器知道 stamps 应该只包含 Stamp 实例，并给予保证（ guarantee），假设整个代码库在编译过程中都没有发出任何警告 。当 stamps利用一个参数化的类型进行声明时，错误的插入会产生一条编译时的错误消息，告诉你具体是哪里出错了。
从集合中检索元素时，编译器会替你插入隐式的转换，并确保它们不会失败（依然假设所有代码都没有产生或者隐瞒任何编译警告） 。 假设不小心将 coin 插入 stamp 集合，这显得有点牵强，但这类问题却是真实的 。 例如，很容易想象有人会不小心将一个Biginteger 实例放进一个原本只包含 BigDecimal 实例的集合中 。
如上所述，使用原生态类型（没有类型参数的泛型）是合法的，但是永远不应该这么做 。 如果使用原生态类型，就失掉了泛型在安全性和描述性方面的所有优势 。 既然不应该使用原生态类型 ，为什么 Java 语言的设计者还要允许使用它们呢？这是为了提供兼容性 。
因为泛型出现的时候，Java 平台即将进入它的第二个十年，已经存在大量没有使用泛型的Java 代码 。 人们认为让所有这些代码保持合法，并且能够与使用泛型的新代码互用，这一点很重要。它必须合法才能将参数化类型的实例传递给那些被设计成使用普通类型的方法，反之亦然 。 这种需求被称作移植兼容性（ Migration Compatibility ），促成了支持原生态类型，以及利用擦除（ erasure) 实现泛型的决定 。
虽然不应该在新代码中使用像 List 这样的原生态类型，使用参数化的类型以允许插入任意对象（比如 List
为了更具体地进行说明，请参考下面的程序：
public static void main(String[] args) {
List strings = new ArrayList<>();
unsafeAdd(strings, Integer.value0f(42));
String s = strings.get(0); // Has compiler-generated cast
private static void unsafeAdd(List list, object o) {
list.add(o);
}
这段程序可以进行编译，但是因为它使用了原生态类型 List ，你会收到一条警告：
实际上，如果运行这段程序，在程序试图将 strings.get(o）的调用结果 Integer转换成 String时，你会收到一个 ClassCastException 异常 。 这是一个编译器生成的转换，因此一般保证会成功，但是我们在这个例子中忽略了一条编译器警告，为此付出了代价 。如果在 unsafeAdd 声明中用参数化类型 List 在不确定或者不在乎集合中的元素类型的情况下，你也许会使用原生态类型 。 例如，假设想要编写一个方法，它有两个集合，并从中返回它们共有元素的数量 。 如果你对泛型还不熟悉，可以参考以下方式来编写这种方法： 这个方法可行，但它使用了原生态类型，这是很危险的 。 安全的替代做法是使用无限制的通配符类型（ unbounded wildcard type ） 。 如果要使用泛型，但不确定或者不关心实际的类型参数，就可以用一个问号代替 。 例如，泛型 Set 无限制通配类型 Set ＜＞和原生态类型 Set 之间有什么区别呢？这个问号真正起到作用了吗？这一点不需要赘述，但通配符类型是安全的，原生态类型则不安全 。 由于可以将任何元素放进使用原生态类型的集合中，因此很容易破坏该集合的类型约束条件（如之前范例中所示的 unsafeAdd 方法）；但不能将任何元素（除了 null 之 外）放到 Collection < ?>中 。 如果尝试这么做，将会产生一条像这样的编译时错误消息： 这样的错误消息显然无法令人满意，但是编译器已经尽到了它的职责，防止你破坏集合的类型约束条件 。 你不仅无法将任何元素（除了 null 之外）放进 Collection ＜？＞ 中，而且根本无法猜测你会得到哪种类型的对象 。 要是无法接受这些限制，就可以使用泛型方法或者有限制的通配符类型 。 不要使用原生态类型，这条规则有几个小小的例外 。 必须在类文字中 使用原生态类型 。 规范不允许使用参数化类型（虽然允许数组类型和基本类型）。换句话说， List.class 、 String[].class 和 int.class 都合法，但是 List 这条规则的第二个例外与 ins ta口 ceof 操作符有关 。 由于泛型信息可以在运行时被擦除，因此在参数化类型而非无限制通配柯：类型上使用 instanceof 操作符是非法的 。 用无限制通配符类型代替原生态类型，对 instanceof 操作符的行为不会产生任何影响 。 在这种情况下，尖括号（ ＜＞）和问号（？）就显得多余了 。 下面是利用泛型来使用 instanceof操作符的首选方法 ： 注意，一旦确定这个 o 是个 Set ，就必须将它转换成通配符类型 Set ＜？＞，而不是转换成原生态类型 Set 。 这是个受检的（ checked ）转换，因此不会导致编译时警告 。 总而言之，使用原生态类型会在运行时导致异常，因此不要使用 。 原生态类型只是为了与引人泛型之前的遗留代码进行兼容和互用而提供的 。 让我们做个快速的回顾：Set
static int numElementsInCommon(Set s1, Set s2) {
int result = 0;
for (Object o1 : s1)
if (s2.contains(o1))
result++;
return result;
}
static int numElementsInCommon(Set s1， Set s2) {...}
if (o instanceof Set) {
Set s = (Set) o;
}