诊断Java代码: 轻松掌握Java泛型，第3部分 - 编程入门网

该方法类似于在 C++ 标准模板库中完成的事情（这使我们有理由担心它不是一个好方法）。该方法的问题是，和为错误的构造函数调用报告错误一样，程序员将无法预知其程序的某一次运行将崩溃。例如，假设实例化数的界限为 42，并且使用用户提供的参数调用先前提到的 nest() 方法。那么，只要用户输入小于 42 的数，一切都正常。当用户输入 43 时，这一计划不周的设计就会失败。现在，设想一下可怜的代码维护者，他所面对的任务是重新组合代码并试图弄清楚幻数 42 有什么特殊之处。

第 2 种：静态禁止多态递归

为什么我们不向编译器发出类似“静态禁止多态递归”这样的命令呢？（唉！要是那么简单就好了。）当然，包括我在内的许多程序员都会反对这种策略，它抑制了许多重要设计模式的使用。

例如，在泛型类 List<T> 中，您真的想要防止 List<List<T>> 的构造吗？从方法返回这种列表对于构建许多很常用的数据结构很有用。事实证明我们无法防止多态递归，即使我们想要那样，也是如此。就象静态检测糟糕的泛型构造函数调用一样，禁止多态递归会与递增式类编译发生冲突。我们先前的简单示例（其中，多态递归作为一个简单直接的自引用发生）会使这一事实变得模糊。但是，自引用对于在不同时间编译的大多数类常常采用任意的间接级别。再提一次，那是因为一个泛型类可以用其自己的类型参数来实例化另一个泛型类。

下面的示例涉及两个类之间的多态递归：

清单 3. 相互递归的多态递归

class C<T> { 　 public Object potentialNest(int n) { 　　 if (n == 0) return this; 　　 else return new D<T>().nest(n - 1); 　 } } class D<S> { 　 public Object nest(int n) { 　　 return new C<C<S>>().nest(n); 　 } }

在类 C 或 D 中显然没有多态递归，但象 new D<C<Object>>().nest(1000) 之类的表达式将引起类 C 的 1000 次实例化。

或许，我们可以将新属性添加到类文件中，以表明类中所有不同泛型类型实例化，然后在编译其它类时分析这些实例化，以进行递归。但是，我们还是必须向程序员提供奇怪的和不直观的错误消息。

在上面的代码中，我们在哪里报告错误呢？在类 D 的编译过程中还是在包含不相干表达式 new D<C<Object>>().nest(1000) 的客户机类的编译过程中呢？无论是哪一种，除非程序员有权访问类 C 的源代码，否则他无法预知何时会发生编译错误。

第 3 种：实时构造新的实例化类

另一种方法是在程序运行时按需构造新的实例化类。起先，这种方法似乎与 Java 运行时完全不兼容。但实际上，实现该策略所需的全部就是使用一个修改的类装入器，它根据“模板（template）”类文件构造新的实例化类。

JVM 规范已经允许程序员使用修改的类装入器；事实上，许多流行的 Java 应用程序（如 Ant、JUnit 和 DrJava）都使用它们。该方法的缺点是：修改的类装入器必须与其应用程序一起分布，以在较旧的 JVM 上运行。因为类装入器往往比较小，所以这个开销不会大。

让我们研究一下该方法的工作示例。

NextGen 示例：修改的类装入器

前一种方法 ― 用按需构造泛型类型实例化的修改的类装入器解决多态递归问题 ― 被 Java 语言的 NextGen 扩展所采用。修改的类装入器使用看上去几乎与普通类文件完全一样的模板文件，不同的是这个模板文件在常量池中有一些“洞”，在装入时为每个实例化类填充这些“洞”。非泛型类不受影响。

在 Rice 大学 JavaPLT 编程语言实验室，我们最近发布了 NextGen 编译器的原型，它是 GJ 泛型 Ja

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!