J2SE(TM) 5.0引入了很多激进的语言元素变化，这些变化或多或少减轻了我们开发人员的一些编码负担，其中的大部分也必然会被应用到即将发布的 J2EE(TM) 5.0中。主要的新特性包括：
· 泛型
· 增强的for循环
· 自动装箱和自动拆箱
· 类型安全的枚举
· 可变长度参数
· 静态引入
· 元数据(注解)
· C风格的格式化输出
这当中，泛型、枚举和注解可能会占用较大的篇幅，而其余的因为用法直截了当，抑或相对简单，我就稍作介绍，剩下的留给读者去思考、去探索了。
1.4. 泛型
泛型这个题目相当大，大到完全可以就这个话题写一本书。有关Java是否需要泛型和如何实现泛型的讨论也早就在Java社群广为流传。终于，我们在J2SE(TM) 5.0中看到了它。也许目前Java对泛型的支持还算不上足够理想，但这一特性的添加也经足以让我们欣喜一阵了。
在接下来的介绍中，我们会了解到：Java的泛型虽然跟C++的泛型看上去十分相似，但其实有着相当大的区别，有些细节的东西也相当复杂(至少很多地方会跟我们的直觉背道而驰)。可以这样说，泛型的引入在很大程度上增加了Java语言的复杂度，对初学者尤其是个挑战。下面我们将一点一点往里挖。
首先我们来看一个简单的使用泛型类的例子：
ArrayList<Integer> aList = new ArrayList<Integer>();
aList.add(new Integer(1));
// ...
Integer myInteger = aList.get(0);
我们可以看到，在这个简单的例子中，我们在定义aList的时候指明了它是一个直接受Integer类型的ArrayList，当我们调用aList.get(0)时，我们已经不再需要先显式的将结果转换成Integer，然后再赋值给myInteger了。而这一步在早先的Java版本中是必须的。也许你在想，在使用Collection时节约一些类型转换就是Java泛型的全部吗?远不止。单就这个例子而言，泛型至少还有一个更大的好处，那就是使用了泛型的容器类变得更加健壮：早先，Collection接口的get()和Iterator接口的next()方法都只能返回Object类型的结果，我们可以把这个结果强制转换成任何Object的子类，而不会有任何编译期的错误，但这显然很可能带来严重的运行期错误，因为在代码中确定从某个Collection中取出的是什么类型的对象完全是调用者自己说了算，而调用者也许并不清楚放进Collection的对象具体是什么类的;就算知道放进去的对象“应该”是什么类，也不能保证放到Collection的对象就一定是那个类的实例。现在有了泛型，只要我们定义的时候指明该Collection接受哪种类型的对象，编译器可以帮我们避免类似的问题溜到产品中。我们在实际工作中其实已经看到了太多的ClassCastException，不是吗?
泛型的使用从这个例子看也是相当易懂。我们在定义ArrayList时，通过类名后面的<>括号中的值指定这个ArrayList接受的对象类型。在编译的时候，这个ArrayList会被处理成只接受该类或其子类的对象，于是任何试图将其他类型的对象添加进来的语句都会被编译器拒绝。
那么泛型是怎样定义的呢?看看下面这一段示例代码：(其中用E代替在实际中将会使用的类名，当然你也可以使用别的名称，习惯上在这里使用大写的E，表示Collection的元素。)
public class TestGenerics<E> {
Collection<E> col;
public void doSth(E elem) {
col.add(elem);
// ...
}
}
在泛型的使用中，有一个很容易有的误解，那就是既然Integer是从Object派生出来的，那么ArrayList<Integer>当然就是ArrayList<Object>的子类。真的是这样吗？我们仔细想一想就会发现这样做可能会带来的问题：如果我们可以把ArrayList<Integer>向上转型为ArrayList<Object>，那么在往这个转了型以后的ArrayList中添加对象的时候，我们岂不是可以添加任何类型的对象（因为Object是所有对象的公共父类）？这显然让我们的ArrayList<Integer>失去了原本的目的。于是Java编译器禁止我们这样做。那既然是这样，ArrayList<Integer>以及ArrayList<String>、ArrayList<Double>等等有没有公共的父类呢？有，那就是ArrayList<?>。?在这里叫做通配符。我们为了缩小通配符所指代的范围，通常也需要这样写：ArrayList<? extends SomeClass>，这样写的含义是定义这样一个类ArrayList，比方说SomeClass有SomeExtendedClass1和SomeExtendedClass2这两个子类，那么ArrayList<? extends SomeClass>就是如下几个类的父类：ArrayList<SomeClass>、ArrayList<SomeExtendedClass1>和ArrayList<SomeExtendedClass2>。
接下来我们更进一步：既然ArrayList<? extends SomeClass>是一个通配的公用父类，那么我们可不可以往声明为ArrayList<? extends SomeClass>的ArrayList实例中添加一个SomeExtendedClass1的对象呢？答案是不能。甚至你不能添加任何对象。为什么？因为ArrayList<? extends SomeClass>实际上代表了所有ArrayList<SomeClass>、ArrayList<SomeExtendedClass1>和ArrayList<SomeExtendedClass2>三种ArrayList，甚至包括未知的接受SomeClass其他子类对象的ArrayList。我们拿到一个定义为ArrayList<? extends SomeClass>的ArrayList的时候，我们并不能确定这个ArrayList具体是使用哪个类作为参数定义的，因此编译器也无法让这段代码编译通过。举例来讲，如果我们想往这个ArrayList中放一个SomeExtendedClass2的对象，我们如何保证它实际上不是其他的如ArrayList<SomeExtendedClass1>，而就是这个ArrayList<SomeExtendedClass2>呢？（还记得吗？ArrayList<Integer>并非ArrayList<Object>的子类。）怎么办？我们需要使用泛型方法。泛型方法的定义类似下面的例子：
public static <T extends SomeClass> void add (Collection<T> c, T elem) {
c.add(elem);
}
其中T代表了我们这个方法期待的那个最终的具体的类，相关的声明必须放在方法签名中紧靠返回类型的位置之前。在本例中，它可以是SomeClass或者SomeClass的任何子类，其说明 放在void关键字之前(只能放在这里)。这样我们就可以让编译器确信当我们试图添加一个元素到泛型的ArrayList实例中时，可以保证类型安全。
Java泛型的最大特点在于它是在语言级别实现的，区别于C# 2.0中的CLR级别。这样的做法使得JRE可以不必做大的调整，缺点是无法支持一些运行时的类型甄别。一旦编译，它就被写死了，能提供的动态能力相当弱。
个人认为泛型是这次J2SE(TM) 5.0中引入的最重要的语言元素，给Java语言带来的影响也是最大。举个例子来讲，我们可以看到，几乎所有的Collections API都被更新成支持泛型的版本。这样做带来的好处是显而易见的，那就是减少代码重复(不需要提供多个版本的某一个类或者接口以支持不同类的对象)以及增强代码的健壮性(编译期的类型安全检查)。不过如何才能真正利用好这个特性，尤其是如何实现自己的泛型接口或类供他人使用，就并非那么显而易见了。让我们一起在使用中慢慢积累。
1.5. 增强的for循环
你是否已经厌倦了每次写for循环时都要写上那些机械的代码，尤其当你需要遍历数组或者Collection，如：(假设在Collection中储存的对象是String类型的)
public void showAll (Collection c) {
for (Iterator iter = c.iterator(); iter.hasNext(); ) {
System.out.println((String) iter.next());
}
}
public void showAll (String[] sa) {
for (int i = 0; i < sa.length; i++) {
System.out.println(sa[i]);
}
}
这样的代码不仅显得臃肿，而且容易出错，我想我们大家在刚开始接触编程时，尤其是C/C++和Java，可能多少都犯过以下类似错误的一种或几种：把for语句的三个表达式顺序弄错;第二个表达式逻辑判断不正确(漏掉一些、多出一些、甚至死循环);忘记移动游标;在循环体内不小心改变了游标的位置等等。为什么不能让编译器帮我们处理这些细节呢?在5.0中，我们可以这样写：
public void showAll (Collection c) {
for (Object obj : c) {
System.out.println((String) obj);
}
}
public void showAll (String[] sa) {
for (String str : sa) {
System.out.println(str);
}
}
这样的代码显得更加清晰和简洁，不是吗?具体的语法很简单：使用":"分隔开，前面的部分写明从数组或Collection中将要取出的类型，以及使用的临时变量的名字，后面的部分写上数组或者Collection的引用。加上泛型，我们甚至可以把第一个方法变得更加漂亮：
public void showAll (Collection<String> cs) {
for (String str : cs) {
System.out.println(str);
}
}
有没有发现：当你需要将Collection 替换成String[]，你所需要做的仅仅是简单的把参数类型"Collection "替换成"String[]"，反过来也是一样，你不完全需要改其他的东西。这在J2SE(TM) 5.0之前是无法想象的。
对于这个看上去相当方便的新语言元素，当你需要在循环体中访问游标的时候，会显得很别扭：比方说，当我们处理一个链表，需要更新其中某一个元素，或者删除某个元素等等。这个时候，你无法在循环体内获得你需要的游标信息，于是需要回退到原先的做法。不过，有了泛型和增强的for循环，我们在大多数情况下已经不用去操心那些烦人的for循环的表达式和嵌套了。毕竟，我们大部分时间都不会需要去了解游标的具体位置，我们只需要遍历数组或Collection，对吧?
1.6. 自动装箱/自动拆箱
所谓装箱，就是把值类型用它们相对应的引用类型包起来，使它们可以具有对象的特质，如我们可以把int型包装成Integer类的对象，或者把double包装成Double，等等。所谓拆箱，就是跟装箱的方向相反，将Integer及Double这样的引用类型的对象重新简化为值类型的数据。
在J2SE(TM) 5.0发布之前，我们只能手工的处理装箱和拆箱。也许你会问，为什么需要装箱和拆箱?比方说当我们试图将一个值类型的数据添加到一个Collection中时，就需要先把它装箱，因为Collection的add()方法只接受对象;而当我们需要在稍后将这条数据取出来，而又希望使用它对应的值类型进行操作时，我们又需要将它拆箱成值类型的版本。现在，编译器可以帮我们自动地完成这些必要的步骤。下面的代码我提供两个版本的装箱和拆箱，一个版本使用手工的方式，另一个版本则把这些显而易见的代码交给编译器去完成：
public static void manualBoxingUnboxing(int i) {
ArrayList<Integer> aList = new ArrayList<Integer>();
aList.add(0, new Integer(i));
int a = aList.get(0).intValue();
System.out.println("The value of i is " + a);
}
public static void autoBoxingUnboxing(int i) {
ArrayList<Integer> aList = new ArrayList<Integer>();
aList.add(0, i);
int a = aList.get(0);
System.out.println("The value of i is " + a);
}
看到了吧，在J2SE(TM) 5.0中，我们不再需要显式的去将一个值类型的数据转换成相应的对象，从而把它作为对象传给其他方法，也不必手工的将那个代表一个数值的对象拆箱为相应的值类型数据，只要你提供的信息足够让编译器确信这些装箱/拆箱后的类型在使用时是合法的：比方讲，如果在上面的代码中，如果我们使用的不是ArrayList 而是ArrayList或者其他不兼容的版本如ArrayList ，会有编译错误。
当然，你需要足够重视的是：一方面，对于值类型和引用类型，在资源的占用上有相当大的区别;另一方面，装箱和拆箱会带来额外的开销。在使用这一方便特性的同时，请不要忘记了背后隐藏的这些也许会影响性能的因素。
1.7. 类型安全的枚举
在介绍J2SE(TM) 5.0中引入的类型安全枚举的用法之前，我想先简单介绍一下这一话题的背景。
我们知道，在C中，我们可以定义枚举类型来使用别名代替一个集合中的不同元素，通常是用于描述那些可以归为一类，而又具备有限数量的类别或者概念，如月份、颜色、扑克牌、太阳系的行星、五大洲、四大洋、季节、学科、四则运算符，等等。它们通常看上去是这个样子：
typedef enum {SPRING, SUMMER, AUTUMN, WINTER} season;
实质上，这些别名被处理成int常量，比如0代表SPRING，1代表SUMMER，以此类推。因为这些别名最终就是int，于是你可以对它们进行四则运算，这就造成了语意上的不明确。
Java一开始并没有考虑引入枚举的概念，也许是出于保持Java语言简洁的考虑，但是使用Java的广大开发者对于枚举的需求并没有因为Java本身没有提供而消失，于是出现了一些常见的适用于Java的枚举设计模式，如int enum和typesafe enum，还有不少开源的枚举API和不开源的内部实现。
我大致说一下int enum模式和typesafe enum模式。所谓int enum模式就是模仿C中对enum的实现，如：
public class Season {
public static final int SPRING = 0;
public static final int SUMMER = 1;
public static final int AUTUMN = 2;
public static final int WINTER = 3;
}
这种模式跟C中的枚举没有太多本质上的区别，C枚举的局限它基本上也有。而typesafe enum模式则要显得健壮得多：
public class Season {
private final String name;
private Season(String name) {
this.name = name;
}
public String toString() {
return name;
}
public static final Season SPRING = new Season("spring");
public static final Season SUMMER = new Season("summer");
public static final Season AUTUMN = new Season("autumn");
public static final Season WINTER = new Season("winter");
}
后一种实现首先通过私有的构造方法阻止了对该类的继承和显式实例化，因而我们只可能取得定义好的四种Season类别，并且提供了方便的toString()方法获取有意义的说明，而且由于这是一个完全意义上的类，所以我们可以很方便的加入自己的方法和逻辑来自定义我们的枚举类。
最终，Java决定拥抱枚举，在J2SE(TM) 5.0中，我们看到了这一变化，它所采用的设计思路基本上就是上面提到的typesafe enum模式。它的语法很简单，用一个实际的例子来说，要定义一个枚举，我们可以这样写：
public enum Language {CHINESE, ENGLISH, FRENCH, HUNGARIAN}
接下来我们就可以通过Language.ENGLISH来使用了。呃…这个例子是不是有点太小儿科了，我们来看一个复杂点的例子。使用Java的类型安全枚举，我们可以为所有枚举元素定义公用的接口，然后具体到每个元素本身，可以针对这些接口实现一些特定的行为。这对于那些可以归为一类，又希望能通过统一的接口访问的不同操作，将会相当方便。通常，为了实现类似的功能，我们需要自己来维护一套继承关系或者类似的枚举模式。这里借用Java官方网站上的一个例子：
public enum Operation {
PLUS { double eval(double x, double y) { return x + y; } },
MINUS { double eval(double x, double y) { return x - y; } },
TIMES { double eval(double x, double y) { return x * y; } },
DIVIDE { double eval(double x, double y) { return x / y; } };
// Do arithmetic op represented by this constant
abstract double eval(double x, double y);
}
在这个枚举中，我们定义了四个元素，分别对应加减乘除四则运算，对于每一种运算，我们都可以调用eval()方法，而具体的方法实现各异。我们可以通过下面的代码来试验上面这个枚举类：
public static void main(String args[]) {
double x = Double.parseDouble(args[0]);
double y = Double.parseDouble(args[1]);
for (Operation op : Operation.values()) {
System.out.println(x + " " + op + " " + y + " = " + op.eval(x, y));
}
}
怎么样，使用枚举，我们是不是能够很方便的实现一些有趣的功能?其实说穿了，Java的类型安全枚举就是包含了有限数量的已生成好的自身实例的一种类，这些现成的实例可以通过类的静态字段来获取。
1.8. 可变长度参数
顾名思义，可变长度参数就是指在方法的参数体中，只要定义恰当，我们可以使用任意数量的参数，类似于使用数组。在J2SE(TM) 5.0中，一个新的语法被引入，就是在参数类型名称后面加上"..."，表示该方法可以接受多个该类型的参数。需要说明的是可变长度参数必须放在参数列表的最后，且一个方法只能包含一个这样的参数。在方法体内部，这样的参数被当作数组处理，看上去代码应该类似这个样子：
public String testVararg(String... args) {
StringBuilder sb = new StringBuilder();
for (String str : args) {
sb.append(str);
}
return sb.toString();
}
这样的方法签名跟你写成testVararg(String[] args)的区别在于：在调用时，你不再需要传入一个包装好的String数组，你只需要简单的写一连串String参数，以逗号隔开即可，就如同这个方法正好有一个重载的版本是接受那么多个String参数一样。
1.9. 静态引入
所谓静态引入就是指除了引入类之外，我们现在又多了一种选择：引入某个类的静态字段。如：
import static java.lang.Math.PI;
或者
import static java.lang.Math.*;
这样我们在接下来的代码中，当我们需要使用某个被引入的静态字段时，就不用再写上前面的类名了。当然，出现名字冲突时，跟原来的类引入一样，还是需要前缀以示区分。我个人认为这个新语言元素意义不大。当引入太多静态字段后，代码会变得难以阅读和维护。由于静态字段的名字通常不如类名那么具有描述性，我认为原先在静态字段前写上类名才是更好的选择。不过，毕竟每个人的喜好和需求不同，如果你觉得它对你有用，既然提供了，那么就用咯。
1.10. 元数据(注解)
注解是J2SE(TM) 5.0引入的重要语言元素，它所对应的JSR是JSR 175，我们先来看看JSR 175的文档对注解的说明：
注解不会直接影响程序的语义，而开发和部署工具则可以读取这些注解信息，并作相应处理，如生成额外的Java源代码、XML文档、或者其他将与包含注解的程序一起使用的物件。
在之前的J2SE版本中，我们已经使用到了一部分早期的注解元素，如@deprecated等。这些元素通常被用于产生HTML的Javadoc。在J2SE(TM) 5.0中，注解被正式引入，且推到了Java历史上前所未有的高度。
现在，注解不仅仅被用来产生Javadoc，更重要的，注解使得代码的编译期检查更加有效和方便，同时也增强了代码的描述能力。有一些注解是随着J2SE(TM) 5.0一起发布的，我们可以直接使用。除此之外，我们也可以很方便的实现自定义的注解。在此基础上，很多以前我们只能靠反射机制来完成的功能也变得更加容易实现。
我们来看现成的有哪些有用的注解：
首先是@Override，这个注解被使用在方法上，表明这个方法是从其父类继承下来的，这样的写法可以很方便的避免我们在重写继承下来的方法时，不至于不小心写错了方法签名，且悄悄的溜过了编译器，造成隐蔽性相当高的bug。
其次是@Deprecated，表明该项(类、字段、方法)不再被推荐使用。
还有一个@SuppressWarnings，表明该项(类、字段、方法)所涵盖的范围不需要显示所有的警告信息。这个注解需要提供参数，如unchecked等等。
下面我通过一个例子向大家说明这些现成的注解的用法：
public class Main {
@Deprecated
public String str;
public static void main(String[] args) {
new SubMain().doSomething();
}
public void doSomething() {
System.out.println("Done.");
}
}
class SubMain extends Main {
@Override
@SuppressWarnings("unchecked", "warning")
public void doSomething() {
java.util.ArrayList aList = new java.util.ArrayList();
aList.add(new Integer(0));
System.out.println("Done by SubMain.");
}
}
当然，我们也完全可以写自己的注解。注解定义的语法是@interface关键字。J2SE(TM) 5.0支持三种形式的注解：不带参数的标记注解、带一个参数的注解和带多个参数的完整注解。下面分别举例说明：
标记注解，类似@Deprecated，如：
@interface SomeEmptyAnnotation {}
单个参数的注解，如：
@interface MySingleElementAnnotation {
String value();
}
以及多个参数的注解，如：
@interface MyAnnotationForMethods {
int index();
String info();
String developer() default "Sean GAO";
}
我们可以看到，注解的定义跟interface的定义相当类似，我们还可以指定默认值。对于这些注解，我们也可以为其添加注解，所谓“注解的注解”。比方讲，我们通常会使用@Target指定注解的作用对象，以及用@Retention指定注解信息写入的级别，如源代码、类文件等等。举个例子：
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.SOURCE)
public @interface SignedMethod {
}
在使用时，我们需要在注解名称前面写上@，然后()中指定参数值，如：
@MyAnnotationForMethods (
index = 1,
info = "This is a method to test MyAnnotation.",
developer = "Somebody else"
)
public void testMethod1() {
// ...
}
注解的最大作用在于它在源代码的基础上增加了有用的信息，使得源代码的描述性更强。这些信息可以被代码之外的工具识别，从而可以很方便的增加外部功能，以及减少不必要的相关代码/文件的维护。这里我想简单提一个超出J2SE(TM) 5.0范畴的话题：在未来的EJB 3.0规范中会有相当多的对注解的应用，让我们预览一下将来的无状态会话bean用注解来定义会是什么样子：
@Stateless public class BookShelfManagerBean {
public void addBook(Book aBook) {
// business logic goes here...
}
public Collection getAllBooks() {
// business logic goes here...
}
// ...
}
我们甚至不用写任何接口和部署描述符，这些工作将完全由外部工具通过读取注解加上反射来完成，这不是很好吗?
1.11. C风格格式化输出
Java总算也有类似C的printf()风格的方法了，方法名同样叫作printf()，这一特性依赖于前边提到的可变长度参数。举个例子来说，我们现在可以写：
System.out.printf("%s has a value of %d.%n", someString, a);
怎么样，看上去还不错吧?需要注意的是Java为了支持多平台，新增了%n标示符，作为对\n的补充。有关Java格式化输出的具体语法，请参考java.util.Formatter的API文档。
1.12. 结语
在这一篇介绍性的文章中，我们一起领略了J2SE 5.0带来的新的语言元素，不知道大家是否也跟笔者一样，感受到了这些新特性在提高我们的开发效率上所作的巨大努力。其实不只是语言元素，J2SE(TM) 5.0的发布在其他很多方面都作了不小的改进，包括虚拟机、新的API类库等等，性能和功能上都有大幅提升。
对于主要靠J2EE吃饭的朋友来讲，也许真正意义上要在工作中充分利用这些新的元素，恐怕要等主流的J2EE服务器都支持J2EE(TM) 5.0的那一天了，对此我充满期待。