代号为“猛虎”（Tiger）的J2SE 1.5计划于今年晚些时候发布。对于这个万众瞩目的新版本，
没有比Joshua Bloch 更适合来介绍它的了。在一次问答式的访谈中，这位卡内基-梅隆大学的
计算机博士、Java Collection 框架的设计者、畅销书Effective Java 的作者、Java 开发者的
“教父”详细地介绍了J2SE 1.5的6 大新特性??这篇访谈中充斥着大量的代码，我很想知道
这位作者是如何采访Bloch 先生的J
Joshua Bloch 表示，J2SE 1.5的核心设计思想就是简化开发者的工作，将重复性的编码工作
交给编译器，使代码更整洁、更简练、更坚固、更可维护。由于Java 日益成为一种服务器端应
用程序开发的语言，因此效率在很大程度上已经不是它最着重考虑的方面。J2SE 1.5 有6 项最
主要的新特性：
Ø 泛型
Ø 增强的for 循环
Ø 自动装箱/拆箱
Ø 类型安全的枚举
Ø 静态导入
Ø 元数据
下面，我们分别来了解这6 项新特性。
泛型（generics）
基于JSR 14 的泛型Java 已经受到了很多的关注。侯捷先生去年就曾在专栏文章中介绍泛型
Java 的实现和使用。在Java 中，泛型主要应用在容器（collection）数据类型。它可以使容器
具有类型安全性，并且避免了在读取容器所容纳的元素时进行强制类型转换。例如，下列代码：
/**
* Remove the four-letter words from the specified
* collection, which must contain only strings.
*/
static void expurgate(Collection c) {
for (Iterator i = c.iterator(); i.hasNext(); ) {
String s = (String) i.next();
if(s.length() == 4)
i.remove();
}
}
在使用泛型容器之后将变成这样：
/**
* Remove the four-letter words from the specified collection of strings.
*/
static void expurgate(Collection<String> c) {
for (Iterator<String> i = c.iterator(); i.hasNext(); )
if (i.next().length() == 4)
i.remove();
}
容器c 对装入其中的对象类型有了强制，因此在用iterator 取出元素时也就无须再进行一次类
型转换，代码显得更加清爽。
由于Java 拥有数以百万计的用户，Sun 不可能为了加入泛型机制而要求所有用户更换新的虚拟
机。因此，Java 将采用比较温和的“擦拭法”实现泛型，也就是说，在进行类型检查之后，即
将对象的具体类型信息擦去，从而与原来的非泛型容器对接。显然，使用这种方式实现的泛型容
器将没有任何效率上的优势。与.NET 1.1 提供的强大的泛型机制相比，泛型Java 只是提高了
代码的质量而已??这也和Joshua Bloch 反复强调的“以开发者为本”的精神相吻合。
增强的for 循环（enhanced for loop）
所谓“增强的for 循环”，主要也是针对容器的。使用该项特性时，开发者可以将“利用iterator
遍历容器”的逻辑交给编译器来处理。例如下列代码：
void cancelAll(Collection c) {
for (Iterator i = c.iterator(); i.hasNext(); ) {
TimerTask tt = (TimerTask) i.next();
tt.cancel();
}
}
可以用增强的for 循环改写为：
void cancelAll(Collection c) {
for (Object o : c)
((TimerTask)o).close();
}
编译器判断对象c 是一个Collection 子对象（即是容器）之后，就会允许使用增强的for 循环
形式，并自动取到c 的迭代器，自动遍历c 中的每个元素。
可以看到，上面的代码中仍然有一个强制类型转换（((TimerTask)o).close();）。实际上，这
项特性应该普遍地与泛型结合，以获得最大的利益。结合泛型之后，上述代码变成：
void cancelAll(Collection<TimerTask> c) {
for (TimerTask task : c)
task.cancel();
}
自动装箱/拆箱（auto-boxing/unboxing）
Java 有一个“分裂的类型系统”（split type system），区分原生类型（primitive type，例如
int、char）和非原生类型（non-primitive type，例如类、枚举）。到目前为止，不能把原生
类型放入容器之中，必须首先将其转换成对应的非原生类型（例如int 对应的非原生类型就是
Integer）。自动装箱就是用于帮助处理这项工作的，自动拆箱则是自动装箱的逆过程，将非原
生类型转换为对应的原生类型。
下列代码的功能是生成命令行中词汇出现的频率表：
public class Freq {
private static final Integer ONE = new Integer(1);
public static void main(String args[]) {
// Maps word (String) to frequency (Integer)
Map m = new TreeMap();
for (int i=0; i<args.length; i++) {
Integer freq = (Integer) m.get(args
);
m.put(args, (freq==null ? ONE :
new Integer(freq.intValue() + 1)));
}
System.out.println(m);
}
}
可以看到，Map 容器中只能容纳Integer 对象。因此，为了将一个整数值加1 再放入容器，就
必须使用new Integer(freq.intValue() + 1)这样麻烦的一个语句。在使用自动装箱（以及
泛型）之后，上述代码变成：
public class Freq {
public static void main(String args[]) {
Map<String, Integer> m = new TreeMap<String, Integer>();
for (String word : args)
m.put(word, m.get(word) + 1);
System.out.println(m);
}
}
代码总量减少了将近一半。
另外，如果你对null 进行拆箱，将会得到0。但是，这个结果目前尚未最后确定，也有人认为
对null 的拆箱操作应该抛出NullPointerException。目前，JSR 201 专家组仍在讨论应该采
用哪种方案。
类型安全的枚举（typesafe enum）
在Effective Java 一书中，Joshua Bloch 曾经介绍过类型安全的枚举的优点，并提出了一个
名为“Type Safety Enum”的模式（条款21）。在J2SE 1.5中将加入这一新特性。比起传统
的int 枚举，类型安全的枚举有如下优点：
Ø 提供了编译器类型安全；
Ø 为枚举类型提供了合适的名字空间；
Ø 更加坚固可靠；
Ø 输出的枚举值将带有更多的信息；
Ø 不能将枚举值放入容器；
Ø 可以在枚举类型中加入任意的字段和方法。
新的枚举类型在语法上与C++的枚举非常相似：
enum Season { winter, spring, summer, fall }
下面是一个枚举的例子：
public enum Coin {
penny(1), nickel(5), dime(10), quarter(25);
Coin(int value) { this.value = value; }
private final int value;
public int value() { return value; }
}
从这里可以看到，可以在枚举类型中声明其他的方法。不过，使用枚举类型中的方法是有一定技
巧的。我们先看使用上述枚举类型的代码：
public class CoinTest {
public static void main(String[] args) {
for (Coin c : Coin.VALUES)
System.out.println(c + ": \t"
+ c.value() +"¢ \t" + color(c));
}
private enum CoinColor { copper, nickel, silver }
private static CoinColor color(Coin c) {
switch(c) {
case Coin.penny: return CoinColor.copper;
case Coin.nickel: return CoinColor.nickel;
case Coin.dime:
case Coin.quarter: return CoinColor.silver;
default: throw new AssertionError("Unknown coin: " + c);
}
}
}
尽管枚举类型成为了非原生类型，但仍然可以在switch 语句中使用枚举值进行判断。也可以在
switch 语句中调用枚举类型中的方法，根据返回的值进行判断??这就是使用枚举类型中方法
的技巧。另外请注意：Coin 和CoinColor 两个枚举类型都有一个枚举值名为nickel，但两者并
不冲突，因为它们分属不同的名字空间。
静态导入（static import）
到目前为止，如果想要使用某个静态（static ）成员值，那么你必须用“类名.成员名”的格式。
例如，下列代码是用于取得π值的：
double a = Math.PI;
为了避免每次都必须引用类名，有人想出了一种名为“Constant Interface”的办法：将静态
成员定义在一个接口中，让需要使用这些静态成员的类实现这个接口：
// "Constant Interface" antipattern - do not use!
public interface Physics {
public static final double AVOGADROS_NUMBER = 6.02214199e23;
public static final double BOLTZMANN_CONSTANT = 1.3806503e-23;
public static final double ELECTRON_MASS = 9.10938188e-31;
}
public class Guacamole implements Physics {
public static void main(String[] args) {
double moles = ...;
double molecules = AVOGADROS_NUMBER * moles;
...
}
}
这并不是一个好办法。“使用Physics 常数”是一个实现细节，是Guacamole 类自己的家务事。
但在使用Constant Interface 之后，这些私事却通过接口暴露在众目睽睽之下，这是很糟糕的
事情??如果Guacamole 类想放弃这些常数，改为使用另一个接口提供的常数，那么所有的
client 代码都必须重新编译；另外，Physics 接口的改动也会导致重新编译。所以，Joshua Bloch
将Constant Interface 归纳为一个反模式（anti-pattern），也就是说，你不应该这样做。
有了静态导入的特性之后，就可以彻底将“使用常数”的细节从接口中剥离出来：
import static org.iso.Physics.*;
class Guacamole {
public static void main(String[] args) {
double molecules = AVOGADROS_NUMBER * moles;
...
}
}
而上面那行获得π值的代码则可以改写为：
import static java.lang.Math.*;
...
double a = PI;
元数据（metadata）
在Java 的实际应用（尤其是J2EE）中，很多时候必须编写重复的样板文件（boilerplate）。
例如，如果要定义一个JAX-RPC Web 服务，就必须同时提供接口类和实现类：
public interface CoffeeOrderIF extends java.rmi.Remote {
public Coffee [] getPriceList()
throws java.rmi.RemoteException;
public String orderCoffee(String name, int quantity)
throws java.rmi.RemoteException;
}
public class CoffeeOrderImpl implements CoffeeOrderIF {
public Coffee [] getPriceList() {
...
}
public String orderCoffee(String name, int quantity) {
...
}
}
有了元数据工具之后，就不必再自己动手写这些麻烦并且与业务主题无关的东西了。你可以在源
码中用特定的符号指定需要远程访问的方法，一个工具就会帮助你生成这些样板文件。使用元数
据之后的代码大概是下面这样：
import javax.xml.rpc.*;
public class CoffeeOrder {
@Remote public Coffee [] getPriceList() {
...
}
@Remote public String orderCoffee(String name, int quantity) {
...
}
}
不过，到目前为止，这项特性还是主要针对Web 服务的。JSR 175 提供了一个框架，允许其他
人定义元数据属性和处理工具。现在，唯一基于JSR 175 实现了元数据和处理工具定义的就是
JSR 181，它定义的就是Web 服务元数据集。有一些Web 服务框架（例如Apache 的axis ）
已经可以非常轻易地完成Web 服务的自动部署。在axis 中，你只需编写一个普通的Java 源文
件、将其放置在合适的路径下、并将其后缀名改为“.jws”，axis 就会自动将其部署为Web 服
务。因此，在Java 中加上元数据特性，获益最大的肯定不是Web 服务开发者。
实际上，另外两种颇受关注的编程方法学Aspect Oriented Programming（面向方面编程，
AOP）和Design by Contract（按契约设计，DbC）或许可以从元数据工具中获得更多的帮助。
另外，除了Web 服务之外，其他的J2EE 应用（例如EJB、JSP/Servlet）都需要大量的样板
文件，例如部署描述符、远端代理等等。各大厂商的IDE（例如BEA Workshop 和IBM
WebSphere Studio）中提供了向导来帮助生成这些样板，开源社群则多采用xDoclet 来处理
样板文件。元数据工具可以为他们提供一个统一的标准。
小结
从根本上来说，J2SE 1.5的改进是为了更加方便开发者，使他们编程更加轻松、开发效率更高。
目前，Tiger 项目仍在继续进行，J2SE 1.5还有可能加入其他的新特性，上述6 大新特性也可
能做一些调整。
Joshua Bloch 访谈原文请看：
http://java.sun.com/features/2003/05/bloch_qa.html
