在TSS.com上看到一篇JDK5.0的整理文章，不敢藏私，今天周末有空，翻译好给大家共享。如翻译不好请多多包涵。

Question

静态引用除了在我的注解类Retention和Target中，我很少使用它们。我仍然不是很确信最初增加这个功能的想法（不鼓励通过实现一个接口来重用它的常量而不需要限制和验证它们的这种“反模式”）足够正确以至于需要引入一个新的语言功能，不过时间会给我们答案。我想从某种意义上讲，在我每天的编程中使用IDE已经让引用变得完全过时，于是不管怎么说我大概也不会真正对这个新功能有什么强烈的感受。变量长度参数到目前为止我还没有感到需要这个功能。它可能时而会用起来比较方便，但是我真的不确信它需要给语言带来变化。枚举虽然我一定会对枚举给予理论上的首肯，我还没有真正的把我的代码转换成使用它们，并且我暂时也没有使用它们的想法。我相信当我使用它们时，结果会让我满意并且会使我的代码更加健壮一点。泛型我把最好的留到了最后… 不过因为这个条目会比较长，我会把泛型的讨论留到明天。
自动装箱目前我还没有太多的使用自动装箱，也许因为我隐约有一种失去对我的代码性能控制的感觉。不过我想这个并没有什么实际的道理，自动装箱有时会用起来很方便也使得你的代码更加可读一点。我想我会鼓励开发者在代码中自动装箱的地方作出标记，我相当确信IDE会跟着提供这样的功能。

Answer 1

泛型从哪里说起呢？首先一点，没有人会反对说泛型是一个可以增强代码健壮性的可靠的概念。至于为什么它们在不考虑语言因素的前提下通常会那么有争议是因为它们的具体实现。以我在C++委员会多年任职的经历，我可以担保要将它们做好做对是多么困难的一件事。简单的说，我这样形容Java泛型：我的代码变得更加健壮，但是也更加难懂。那么什么是问题所在呢？不必要的重复。首先，我自始至终都不喜欢由一般的转型需要带来的不必要的重复。例如，与其写：Map accounts = new HashMap();  // no generics
...
Account a = (Account) accounts.get("Cedric");为什么我不能简单的写：Map m = new HashMap();  // no generics
...
Account a = m.get("Cedric");然后让编译器引入一个隐式的转型呢？因为很显然我想从Map中取出的是一个Account类的对象。显然，泛型并不能完全解决这个问题，不过也相当好的减轻了一些。然而它们也在其他地方使事情变得更糟：Map<String, List<Account>> accounts = new HashMap<String, List<Account>>();唉。这样的代码不仅更难读，而且违背了DRY原则（“不要重复自己”）。如果我需要将这个map的值类型从List<Account>改成Collection<Account>怎么办？我需要替换掉我的代码中所有的这样的语句。虽然IDE的重构会有些帮助，但是这仍然是一大堆语义上没有影响的类似修改的代码。我承认当你创建一个新的对象时并没有什么好的方法可以避免这个语法，不过我想表明的是我认为如果typedef也同时被引入的话，泛型也许会做得更好。至少我一开始是这么想的。当我进一步考虑这个问题以后，我意识到typedef并不是解决这个问题的正确方法，因为简单讲，它们顶多只能使用一个单独的类来定义你的复杂泛型类型，除此以外，它们不能做更多的事。class AccountMap extends HashMap<String, List&lAccount>> {
 ...
}除非你需要继承一个实现类（HashMap而不是Map，显然），这一方案也许比引入typedef要来得好，typedef也有自己的毛病。到目前为止我还没有遇到过这样的麻烦，不过我的建议是：当你对同一个类型写了超过三次（初始化的时候两次，然后在代码中使用多于一次）的话就用这种方式吧。除了这一小小的麻烦，我对泛型总体上感到相当满意，尤其当我读到TestND类化得如此好的Javadocs的时候。

Answer 2

结语我对JDK 5.0的新功能感到非常高兴，并且为我能有机会通过参与JSR 175和JSR 201的方式影响它感到荣幸。就像所有的激进的进化一样，并非所有的功能都会受到每个人的欢迎，不过只要大多数开发者觉得某些新功能有用，并且保证向上兼容，我想JDK 5.0是Java迈向更牢固的代码的坚实一步。
关于作者
Cedric Beust [email protected]
Blog: http://www.beust.com/weblog/Cedric Beust是WebLogic Server团队的高级软件工程师，并经常在他的weblog Otaku上发表其对J2EE、 Java、 AOP、以及软件开发的见解。