java泛型契约_轻松掌握 Java 泛型 (第 2 部分)

轻松掌握 Java 泛型 (第 2 部分)

来源：** 收集整理

J2SE 1.5 — 代号为“

JSR-14 原型编译器中预先

型类型的基础知识，以及为

明了为 Tiger 制定的泛型

型类型的上下文。

Tiger” — 计划在 2003 年年

展示的那样，现在可下载获得)

什么它们是对 Java 语言的一个

类型的实现怎么会包含数个“缺

底发布，它将包括泛型类型(如在

。在第 1 部分中，我们讨论了泛

重要且迫切需要的补充。我们还说

陷”，这些缺陷限制了可以使用泛

为了帮助新程序员有效

Tiger 和 JSR-14 中是被禁

)为了在 JVM 上兼容地实

地使用泛型类型，我将详细说明

止的，并将说明为什么这些限制

现泛型类型所使用的实现策略的

到底泛型类型的哪些用法在

是 JSR-14(理所当然还有 Tiger

必然结果。

泛型类型的限制

让我们先查阅一下 Tiger 和 JSR-14 中泛型类型的使用限制：

不应在静态成员中引用封闭类型参数。

不能用基本类型实例化泛型类型参数。

不能在数据类型转换或 instanceof 操作中使用“外露”类型参数。

不能在 new 操作中使用“外露”类型参数。

不能在类定义的 imple

ments 或 extends 子句中使用

“外露”类型参数。

为什么会有这些限制呢？这要归因于

的机制。由于 JVM 根本不支持泛型类型

泛型类型的支持 — 它们用泛型类型信息

生成只包含普通类型的类文件。

Tiger 和 JSR-14 为在 JVM 上实现泛型类型所使用

，所以这些编译器“耍了个花招”，使得似乎存在对

检查所有的代码，但随即“擦除”所有的泛型类型并

例如，将象 List< T> 这样的泛型类型擦除得只剩下 List。“外露”类型参数 — 单独出现而不是位于某个类型中的类型参数(如类 List< T> 中的类型参数 T)— 被简单地擦除成它们的上界(就 T 而言，其上界就是 Object)。

这一技术的功能极其强大；我们可以使几乎所有泛型类型的精度得到增强，但又与 JVM 保持兼容。事实上，我们甚至可以交替地使用非泛型的旧类(比如 List)和其对应的泛型类(List< T>)；两者在运行时看起来是一样的。

遗憾的是，正如以上的限制所示，获

系统中引入了缺陷，这些缺陷限制我们使

得这一功能是有代价的。以这种方式进行擦除在类型

用泛型类型的安全性。

为了帮助说明每种限制

限制。与后两个限制有关的

，我们查阅会出现这些限制的示

问题过于复杂，因而需要更深入

例。在本文中，我们将讨论前三个

的研究，留待下一篇文章讨论。

静态成员中的封闭类型参数

编译器完全禁止在静态方法和静态内

码在 Tiger 中就是非法的：

部类中引用封闭类型参数。所以，举例来说，以下代

清单 1. 在静态上下文中非法引用封闭类型参数 class C< T> {

static void m() {

T t;

}

static class D {

C< T> t;

}

}

当编译这一代码时，会生成两个错误：

在静态方法 m 中非法引用 T 的错误

在静态类 D 中非法引用 T 的错误

当定义静态字段时，情

中共享该类中的静态字段。

明中引用类型参数，编译器

时导致奇怪的错误，如在不

况变得更加复杂。在 JSR-14 和

现在，在 JSR-14 编译器 1.0

不会报错，但它本应该这么做。

包含数据类型转换的代码中出现

Tiger 中，在泛型类的所有实例

和 1.2 中，如果您在静态字段声

字段被共享这一事实很容易在运行

ClassCastException。

例如，以下程序将在这两个版本的 JSR-14 下通过编译而没有任何警告：

清单 2. 在静态字段中对封闭类型参数的有问题的引用 class C< T> {

static T member;

C(T t) { member = t; }

T getMember() { return member; }

public static void

main(String[] args) {

C< String> c = new C< String>("test");

System.out.print

ln(c.getMember().toString())

;

new C< Integer>(new Integer(1));

System.out.println(c.getMemb

er().toString());

}

}

请注意，每次分配类 C 的实例时，都要重新设置静态字段 member。而且，它被设置成的对象类型取决于 C 的实例的类型！在所提供的 main 方法中，第一个实例 c 是 C< String> 类型。而第二个是 C< Integer> 类型。每当从 c 访问 member 这一共享静态字段时，总是假定 member 的类型是 String。但是，在分配了类型为 C< Integer> 的第二个实例之后，member 的类型是 Integer。

运行 C 的 main 方法的结果可能会

源代码根本没有包含任何数据类型转换，

据类型转换插入到代码中，这样做是为了

实。这些数据类型转换被期望能够成功，

让您吃惊 — 它将发出一个 ClassCastException！

怎么会这样呢？事实证明编译器确实在编译阶段将数

解决类型擦除会降低某些表达式的类型的精度这一事

但在本例中却没有成功。

应该认为 JSR-14 1.0

性，或者可以说，它破坏了

做的那样，只要防止程序员

和 1.2 的这一特殊“功能”是

类型系统应该和程序员达成的“

在静态字段中引用泛型类型，情

个错误。它破坏了类型系统的健全

基本契约”。象对静态方法和类所

况就会好很多。

请注意允许这种有潜在

码中覆盖类型系统。问题是

操作，错误地在字段声明中

“爆炸性”的代码存在所带来的

程序员可能会无意中编写这样的

包括静态修饰符)。

问题并不是程序员有意在自己的代

代码(比如，由于“复制和粘贴”

类型检查器应该能帮助程序员从这些

实际上会使程序员更迷惑。当未使用数据

ClassCastException 时，我们应如何诊

的实现方案而又恰好假定类型系统合理运

类型系统不是合理地运行。

类型的错误中恢复，但对于静态字段而言，类型系统

类型转换的代码中显示的唯一错误就是

断这样的错误？对于不清楚 Tiger 中泛型类型所用

行的程序员而言，情况更糟。因为在这样的情况下，

幸运的是，JSR-14 的

此，我们有理由期待在 Tig

最新版本(1.3)宣布在静态字

er 的静态字段中使用类型参数

段中使用类型参数是不合法的。因

也是不合法的。

泛型类型参数和基本类型

和我们刚才讨论的不同，这一限制没有同样的潜在缺陷，但它会使您的代码非常冗长。例如，在 java.util.Hashtable 的泛型版本中，有两种类型参数：用于 Key 类型的和用于 Value 类型的。因此，如果我们想要一个将 String 映射到 String 的 Hashtable，我们可以用表达式 new Hashtable< String, String>() 指定新的实例。但是，如果我们想要一个将 String 映射到 int 的 Hashtable，我们只能创建 Hashtable< String, Integer> 的实例，并将所有的 int 值包装在 Integer 中。

同样，Tiger 在这方面

界限，而界限不能是基本类

。

当然也是由所用的实现方案得到

型，所以一旦类型被擦除，则对

的。既然类型参数被擦除为它们的

基本类型的实例化会完全没有意义

数据类型转换或 instanceof 操作中的“外露”参数

回想一下，对于“外露”类型参数，我们是指在词汇上单独出现的类型参数，而不是更大类型的语法子组件。例如，C< T> 不是“外露”类型参数，但(在 C 主体中)T 是。

如果在代码中对“外露”类型参数进

出名为“unchecked”的警告。例如，以

type T：

行数据类型转换或 instanceof 操作，则编译器将发

下代码将生成警告：Warning: unchecked cast to

清单 3. 带 unchecked

操作的泛型代码 import java.

util.Hashtable;

interface Registry {

public void register(Object o);

}

class C< T> implements Registry {

int counter = 0;

Hashtable< Integer, T> values;

public C() {

values = new Hashtable< Integer, T>();

}

public void register(Object o) {

values.put(new Integer(count

er), (T)o);

counter++;

}

}

您应该严肃地对待这些警告，因为它们说明您的代码在运行时会表现得非常奇怪。事实上，它们会使得诊断代码变得极为困难。在以前的代码中，我们认为如果对实例 C< JFrame> 调用 register("test")，会发出 ClassCastException。但并非如此；计算将继续，就仿佛数据类型转换成功了一样，然后在进一步进行计算时发出错误，或者更糟：用遭破坏的数据完成计算，但不向外发出任何错误信号。同样，对“外露”类型参数的 instanceof 检查将在编译时产生“unchecked”警告，而且检查将不会如期在运行时进行。

双刃剑

那么，这里到底发生了

instanceof 测试中的外露

Object)。因此，对类型

什么？因为 Tiger 依靠类型擦

类型参数被“擦除”为它们的上

参数的数据类型转换将变成对参

除，所以数据类型转换和

界(在前面的例子中，那将是类型

数上界的转换。

同样，instanceof 将

做的，如果是的话，我们完

数据类型转换和 instanceo

检查操作数是否是参数界限的 i

全可以显式地强制转换为界限。

f 检查。

nstanceof。那根本不是我们打算

因此，通常应避免对类型参数使用

然而，有时为了编译代码，您必须依

只要记住，在代码的那一部分中，类型检

靠对类型参数的数据类型转换。如果是这样的情况，

查不保险 — 要靠自己。

尽管泛型类型是制作健

而且极难诊断和修正。下次

型 Java 类型系统中包括它

壮代码的强大武器，但我们已经

，我们将介绍 Tiger 中泛型类

们时必定会出现的一些问题。

发表于:2004.12.24 16:49