J2SE1.5便于开发的新语言特性： Joshua Bloch的访谈录（2） (转)

XML:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" />Office:office" />ASPectratio="t" v:ext="edit">2003-5-121515020.bmp" align=baseline border=0>您能把这六个方面的改进概括一下吗？

那好，我做一个简述：

• 泛型Generic – 提供了collection操作的编译期类型安全，并且避免了类型转换的苦差事。
• For循环增强Enhanced for loop – 避免使用容易引起错误的迭代器.
• 自动置入/自动取出Autoboxing/unboxing – 避免了在基本类型（如int）和包装类型（如Integer）之间人工转换类型的苦差事。
• 类型安全的枚举Typesafe enums – 提供了类型安全的枚举模式（(Java.sun.com/docs/books/effective/">Effective Java, Item 21)）的好处，却没有冗长和易错的代码。
• 静态导入Static import – 让你可以避免使用类的静态变量而必须前缀类名；而且避免了常数接口的缺点(Effective Java, Item 17)。
• 元数据 – 让你避免写样本代码。你在程序中做标记然后工具自动帮你生成样本代码。这会导致一种声明式的程序设计方格，你说应该做什么，然后工具就会产生代码完成这个任务。

如果遵循新规范并且开始使用泛型，那么现在使用集合的方式和使用带泛型的集合有什么不同之处？

我们一般这样使用集合：

/**

 * 在由String构成的集合中删除所有长度为4的元素

 * 传入的集合必须由String构成

*/

static void expurgate(Collection c) {

  for (Iterator i = c.iterator(); i.hasNext(); ) {

  String s = (String) i.next();

  if(s.length() == 4)

  i.remove();

  }

}

这个类型转换并不完美，而且更重要的是程序可能会在运行时发生错误。假设用户不小心传入一个由StringBuffer构成的集合而不是注释中说明的String，那么就可能会有意外发生。注释说客户端必须传入一个由String构成的集合，但是并不能要求编译器编译时一定满足注释。

下面是同样的代码使用泛型的例子 ：

/**

 *在由String构成的集合中删除所有长度为4的元素

 */

static void expurgate(Collection c) {

  for (Iterator i = c.iterator(); i.hasNext(); )

  if (i.next().length() == 4)

  i.remove();

}

现在从代码的签名就可以看出，输入参数必须是仅仅由String构成的集合。如果客户试图传入一个由StringBuffer构成的集合，程序就不会通过编译。而且请注意我们上面的代码中并没有类型转换。它只有短短的一行，而且阅读使用泛型集合的代码也会非常清晰。

请您给我们介绍一下 "for增强"?

我们可以使用更优雅的方法遍历一个集合。你一般遍历集合的时候，都只是取元素，很少用到其他的方法。"for增强"可以让编译器代替你管理你的迭代器。例如，这是一个使用迭代器遍历一个由TimeTask构成的集合：

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();

}

当你读这个语句的时候，其中的分号读作“在其中”。如果我们使用两个新关键字foreach和in将会更加自然，不过引入新关键字会比较麻烦。比如如果我们现有的代码中如果正好使用这两个字作为标志符的话，那么新的编译系统就会破坏我们的原有代码。我们的方法是在保留兼容性的基础扩充语言。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10752019/viewspace-956534/，如需转载，请注明出处，否则将追究法律责任。