泛型（Generic type 或者 generics）是对 Java 语言的类型系统的一种扩展，以支持创建可以按类型进行参数化的类。可以把类型参数看作是使用参数化类型时指定的类型的一个占位符，就像方法的形式参数是运行时传递的值的占位符一样。

可以在集合框架（Collection framework）中看到泛型的动机。例如，Map 类允许您向一个 Map 添加任意类的对象，即使最常见的情况是在给定映射（map）中保存某个特定类型（比如 String）的对象。

因为 Map.get() 被定义为返回 Object，所以一般必须将 Map.get() 的结果强制类型转换为期望的类型，如下面的代码所示：

Map m = new HashMap();
m.put("key", "blarg");
String s = (String) m.get("key");

要让程序通过编译，必须将 get() 的结果强制类型转换为 String，并且希望结果真的是一个 String。但是有可能某人已经在该映射中保存了不是 String 的东西，这样的话，上面的代码将会抛出 ClassCastException。

理想情况下，您可能会得出这样一个观点，即 m 是一个 Map，它将 String 键映射到 String 值。这可以让您消除代码中的强制类型转换，同时获得一个附加的类型检查层，该检查层可以防止有人将错误类型的键或值保存在集合中。这就是泛型所做的工作。

泛型的好处

Java 语言中引入泛型是一个较大的功能增强。不仅语言、类型系统和编译器有了较大的变化，以支持泛型，而且类库也进行了大翻修，所以许多重要的类，比如集合框架，都已经成为泛型化的了。这带来了很多好处：

类型安全。 泛型的主要目标是提高 Java 程序的类型安全。通过知道使用泛型定义的变量的类型限制，编译器可以在一个高得多的程度上验证类型假设。没有泛型，这些假设就只存在于程序员的头脑中（或者如果幸运的话，还存在于代码注释中）。

Java 程序中的一种流行技术是定义这样的集合，即它的元素或键是公共类型的，比如“String 列表”或者“String 到 String 的映射”。通过在变量声明中捕获这一附加的类型信息，泛型允许编译器实施这些附加的类型约束。类型错误现在就可以在编译时被捕获了，而不是在运行时当作 ClassCastException 展示出来。将类型检查从运行时挪到编译时有助于您更容易找到错误，并可提高程序的可靠性。

消除强制类型转换。 泛型的一个附带好处是，消除源代码中的许多强制类型转换。这使得代码更加可读，并且减少了出错机会。

尽管减少强制类型转换可以降低使用泛型类的代码的罗嗦程度，但是声明泛型变量会带来相应的罗嗦。比较下面两个代码例子。

该代码不使用泛型：

List li = new ArrayList();
li.put(new Integer(3));
Integer i =  (Integer) li.get(0);

该代码使用泛型：

List<Integer> li = new ArrayList<Integer>();
li.put(new Integer(3));
Integer i =  li.get(0);

在简单的程序中使用一次泛型变量不会降低罗嗦程度。但是对于多次使用泛型变量的大型程序来说，则可以累积起来降低罗嗦程度。

潜在的性能收益。 泛型为较大的优化带来可能。在泛型的初始实现中，编译器将强制类型转换（没有泛型的话，程序员会指定这些强制类型转换）插入生成的字节码中。但是更多类型信息可用于编译器这一事实，为未来版本的 JVM 的优化带来可能。

由于泛型的实现方式，支持泛型（几乎）不需要 JVM 或类文件更改。所有工作都在编译器中完成，编译器生成类似于没有泛型（和强制类型转换）时所写的代码，只是更能确保类型安全而已。

泛型用法的例子

泛型的许多最佳例子都来自集合框架，因为泛型让您在保存在集合中的元素上指定类型约束。考虑这个使用 Map 类的例子，其中涉及一定程度的优化，即 Map.get() 返回的结果将确实是一个 String：

Map m = new HashMap();
m.put("key", "blarg");
String s = (String) m.get("key");

如果有人已经在映射中放置了不是 String 的其他东西，上面的代码将会抛出 ClassCastException。泛型允许您表达这样的类型约束，即 m 是一个将 String 键映射到 String 值的 Map。这可以消除代码中的强制类型转换，同时获得一个附加的类型检查层，这个检查层可以防止有人将错误类型的键或值保存在集合中。

下面的代码示例展示了 JDK 5.0 中集合框架中的 Map 接口的定义的一部分：

public interface Map<K, V> {
  public void put(K key, V value);
  public V get(K key);
}

注意该接口的两个附加物：

类型参数 K 和 V 在类级别的规格说明，表示在声明一个 Map 类型的变量时指定的类型的占位符。

在 get()、put() 和其他方法的方法签名中使用的 K 和 V。

为了赢得使用泛型的好处，必须在定义或实例化 Map 类型的变量时为 K 和 V 提供具体的值。以一种相对直观的方式做这件事：

Map<String, String> m = new HashMap<String, String>();
m.put("key", "blarg");
String s = m.get("key");

当使用 Map 的泛型化版本时，您不再需要将 Map.get() 的结果强制类型转换为 String，因为编译器知道 get() 将返回一个 String。

在使用泛型的版本中并没有减少键盘录入；实际上，比使用强制类型转换的版本需要做更多键入。使用泛型只是带来了附加的类型安全。因为编译器知道关于您将放进 Map 中的键和值的类型的更多信息，所以类型检查从执行时挪到了编译时，这会提高可靠性并加快开发速度。

向后兼容

在 Java 语言中引入泛型的一个重要目标就是维护向后兼容。尽管 JDK 5.0 的标准类库中的许多类，比如集合框架，都已经泛型化了，但是使用集合类（比如 HashMap 和 ArrayList）的现有代码将继续不加修改地在 JDK 5.0 中工作。当然，没有利用泛型的现有代码将不会赢得泛型的类型安全好处。

二 泛型基础

类型参数

在定义泛型类或声明泛型类的变量时，使用尖括号来指定形式类型参数。形式类型参数与实际类型参数之间的关系类似于形式方法参数与实际方法参数之间的关系，只是类型参数表示类型，而不是表示值。

泛型类中的类型参数几乎可以用于任何可以使用类名的地方。例如，下面是 java.util.Map 接口的定义的摘录：

public interface Map<K, V> {
  public void put(K key, V value);
  public V get(K key);
}

Map 接口是由两个类型参数化的，这两个类型是键类型 K 和值类型 V。（不使用泛型）将会接受或返回 Object 的方法现在在它们的方法签名中使用 K 或 V，指示附加的类型约束位于 Map 的规格说明之下。

当声明或者实例化一个泛型的对象时，必须指定类型参数的值：

Map<String, String> map = new HashMap<String, String>();

注意，在本例中，必须指定两次类型参数。一次是在声明变量 map 的类型时，另一次是在选择 HashMap 类的参数化以便可以实例化正确类型的一个实例时。

编译器在遇到一个 Map<String, String> 类型的变量时，知道 K 和 V 现在被绑定为 String，因此它知道在这样的变量上调用 Map.get() 将会得到 String 类型。

除了异常类型、枚举或匿名内部类以外，任何类都可以具有类型参数。

命名类型参数

推荐的命名约定是使用大写的单个字母名称作为类型参数。这与 C++ 约定有所不同（参阅 附录 A：与 C++ 模板的比较），并反映了大多数泛型类将具有少量类型参数的假定。对于常见的泛型模式，推荐的名称是：

K —— 键，比如映射的键。
V —— 值，比如 List 和 Set 的内容，或者 Map 中的值。
E —— 异常类。
T —— 泛型。

泛型不是协变的

关于泛型的混淆，一个常见的来源就是假设它们像数组一样是协变的。其实它们不是协变的。List<Object> 不是 List<String> 的父类型。

如果 A 扩展 B，那么 A 的数组也是 B 的数组，并且完全可以在需要 B[] 的地方使用 A[]：

Integer[] intArray = new Integer[10]; 
Number[] numberArray = intArray;

上面的代码是有效的，因为一个 Integer 是 一个 Number，因而一个 Integer 数组是 一个 Number 数组。但是对于泛型来说则不然。下面的代码是无效的：

List<Integer> intList = new ArrayList<Integer>();
List<Number> numberList = intList; // invalid

最初，大多数 Java 程序员觉得这缺少协变很烦人，或者甚至是“坏的（broken）”，但是之所以这样有一个很好的原因。如果可以将 List<Integer> 赋给 List<Number>，下面的代码就会违背泛型应该提供的类型安全：

List<Integer> intList = new ArrayList<Integer>();
List<Number> numberList = intList; // invalid
numberList.add(new Float(3.1415));

因为 intList 和 numberList 都是有别名的，如果允许的话，上面的代码就会让您将不是 Integers 的东西放进 intList 中。但是，正如下一屏将会看到的，您有一个更加灵活的方式来定义泛型。

类型通配符

假设您具有该方法：

void printList(List l) {
  for (Object o : l)
    System.out.println(o);
}

上面的代码在 JDK 5.0 上编译通过，但是如果试图用 List<Integer> 调用它，则会得到警告。出现警告是因为，您将泛型（List<Integer>）传递给一个只承诺将它当作 List（所谓的原始类型）的方法，这将破坏使用泛型的类型安全。

如果试图编写像下面这样的方法，那么将会怎么样？

void printList(List<Object> l) {
  for (Object o : l)
    System.out.println(o);
}

它仍然不会通过编译，因为一个 List<Integer> 不是 一个 List<Object>（正如前一屏 泛型不是协变的 中所学的）。这才真正烦人 —— 现在您的泛型版本还没有普通的非泛型版本有用！

解决方案是使用类型通配符：

void printList(List<?> l) {
  for (Object o : l)
    System.out.println(o);
}

上面代码中的问号是一个类型通配符。它读作“问号”。List<?> 是任何泛型 List 的父类型，所以您完全可以将 List<Object>、List<Integer> 或 List<List<List<Flutzpah>>> 传递给 printList()。

类型通配符的作用

前一屏 类型通配符 中引入了类型通配符，这让您可以声明 List<?> 类型的变量。您可以对这样的 List 做什么呢？非常方便，可以从中检索元素，但是不能添加元素。原因不是编译器知道哪些方法修改列表哪些方法不修改列表，而是（大多数）变化的方法比不变化的方法需要更多的类型信息。下面的代码则工作得很好：

List<Integer> li = new ArrayList<Integer>();
li.add(new Integer(42));
List<?> lu = li;
System.out.println(lu.get(0));

为什么该代码能工作呢？对于 lu，编译器一点都不知道 List 的类型参数的值。但是编译器比较聪明，它可以做一些类型推理。在本例中，它推断未知的类型参数必须扩展 Object。（这个特定的推理没有太大的跳跃，但是编译器可以作出一些非常令人佩服的类型推理，后面就会看到（在 底层细节 一节中）。所以它让您调用 List.get() 并推断返回类型为 Object。

另一方面，下面的代码不能工作：

List<Integer> li = new ArrayList<Integer>();
li.add(new Integer(42));
List<?> lu = li;
lu.add(new Integer(43));  // error

在本例中，对于 lu，编译器不能对 List 的类型参数作出足够严密的推理，以确定将 Integer 传递给 List.add() 是类型安全的。所以编译器将不允许您这么做。

以免您仍然认为编译器知道哪些方法更改列表的内容哪些不更改列表内容，请注意下面的代码将能工作，因为它不依赖于编译器必须知道关于 lu 的类型参数的任何信息：

List<Integer> li = new ArrayList<Integer>();
li.add(new Integer(42));
List<?> lu = li;
lu.clear();

泛型方法

（在 类型参数 一节中）您已经看到，通过在类的定义中添加一个形式类型参数列表，可以将类泛型化。方法也可以被泛型化，不管它们定义在其中的类是不是泛型化的。

泛型类在多个方法签名间实施类型约束。在 List<V> 中，类型参数 V 出现在 get()、add()、contains() 等方法的签名中。当创建一个 Map<K, V> 类型的变量时，您就在方法之间宣称一个类型约束。您传递给 add() 的值将与 get() 返回的值的类型相同。

类似地，之所以声明泛型方法，一般是因为您想要在该方法的多个参数之间宣称一个类型约束。例如，下面代码中的 ifThenElse() 方法，根据它的第一个参数的布尔值，它将返回第二个或第三个参数：

public <T> T ifThenElse(boolean b, T first, T second) {
  return b ? first : second;
}

注意，您可以调用 ifThenElse()，而不用显式地告诉编译器，您想要 T 的什么值。编译器不必显式地被告知 T 将具有什么值；它只知道这些值都必须相同。编译器允许您调用下面的代码，因为编译器可以使用类型推理来推断出，替代 T 的 String 满足所有的类型约束：

String s = ifThenElse(b, "a", "b");

类似地，您可以调用：

Integer i = ifThenElse(b, new Integer(1), new Integer(2));

但是，编译器不允许下面的代码，因为没有类型会满足所需的类型约束：

String s = ifThenElse(b, "pi", new Float(3.14));

为什么您选择使用泛型方法，而不是将类型 T 添加到类定义呢？（至少）有两种情况应该这样做：

当泛型方法是静态的时，这种情况下不能使用类类型参数。

当 T 上的类型约束对于方法真正是局部的时，这意味着没有在相同类的另一个 方法签名中使用相同 类型 T 的约束。通过使得泛型方法的类型参数对于方法是局部的，可以简化封闭类型的签名。

有限制类型

在前一屏 泛型方法 的例子中，类型参数 V 是无约束的或无限制的 类型。有时在还没有完全指定类型参数时，需要对类型参数指定附加的约束。

考虑例子 Matrix 类，它使用类型参数 V，该参数由 Number 类来限制：

public class Matrix<V extends Number> { ... }

编译器允许您创建 Matrix<Integer> 或 Matrix<Float> 类型的变量，但是如果您试图定义 Matrix<String> 类型的变量，则会出现错误。类型参数 V 被判断为由 Number 限制 。在没有类型限制时，假设类型参数由 Object 限制。这就是为什么前一屏 泛型方法 中的例子，允许 List.get() 在 List<?> 上调用时返回 Object，即使编译器不知道类型参数 V 的类型。

三 一个简单的泛型类

编写基本的容器类

此时，您可以开始编写简单的泛型类了。到目前为止，泛型类最常见的用例是容器类（比如集合框架）或者值持有者类（比如 WeakReference 或 ThreadLocal）。我们来编写一个类，它类似于 List，充当一个容器。其中，我们使用泛型来表示这样一个约束，即 Lhist 的所有元素将具有相同类型。为了实现起来简单，Lhist 使用一个固定大小的数组来保存值，并且不接受 null 值。

Lhist 类将具有一个类型参数 V（该参数是 Lhist 中的值的类型），并将具有以下方法：

public class Lhist<V> {
  public Lhist(int capacity) { ... }
  public int size() { ... }
  public void add(V value) { ... }
  public void remove(V value) { ... }
  public V get(int index) { ... }
}

要实例化 Lhist，只要在声明时指定类型参数和想要的容量：

Lhist<String> stringList = new Lhist<String>(10);

实现构造函数

在实现 Lhist 类时，您将会遇到的第一个拦路石是实现构造函数。您可能会像下面这样实现它：

public class Lhist<V> {
  private V[] array;
  public Lhist(int capacity) {
    array = new V[capacity]; // illegal
  }
}

这似乎是分配后备数组最自然的一种方式，但是不幸的是，您不能这样做。具体原因很复杂，当学习到 底层细节 一节中的“擦除”主题时，您就会明白。分配后备数组的实现方式很古怪且违反直觉。下面是构造函数的一种可能的实现（该实现使用集合类所采用的方法）：

public class Lhist<V> {
  private V[] array;
  public Lhist(int capacity) {
    array = (V[]) new Object[capacity];
  }
}

另外，也可以使用反射来实例化数组。但是这样做需要给构造函数传递一个附加的参数 —— 一个类常量，比如 Foo.class。后面在 Class<T> 一节中将讨论类常量。

实现方法

实现 Lhist 的方法要容易得多。下面是 Lhist 类的完整实现：

public class Lhist<V> {
    private V[] array;
    private int size;

    public Lhist(int capacity) {
        array = (V[]) new Object[capacity];
    }

    public void add(V value) {
        if (size == array.length)
            throw new IndexOutOfBoundsException(Integer.toString(size));
        else if (value == null)
            throw new NullPointerException();
        array[size++] = value;
    }

    public void remove(V value) {
        int removalCount = 0;
        for (int i=0; i<size; i++) {
            if (array[i].equals(value))
                ++removalCount;
            else if (removalCount > 0) {
                array[i-removalCount] = array[i];
                array[i] = null;
            }
        }
        size -= removalCount;
    }

    public int size() { return size; }

    public V get(int i) {
        if (i >= size)
            throw new IndexOutOfBoundsException(Integer.toString(i));
        return array[i];
    }
}

注意，您在将会接受或返回 V 的方法中使用了形式类型参数 V，但是您一点也不知道 V 具有什么样的方法或域，因为这些对泛型代码是不可知的。

使用 Lhist 类

使用 Lhist 类很容易。要定义一个整数 Lhist，只需要在声明和构造函数中为类型参数提供一个实际值即可：

Lhist<Integer> li = new Lhist<Integer>(30);

编译器知道，li.get() 返回的任何值都将是 Integer 类型，并且它还强制传递给 li.add() 或 li.remove() 的任何东西都是 Integer。除了实现构造函数的方式很古怪之外，您不需要做任何十分特殊的事情以使 Lhist 是一个泛型类。

四 Java类库中的泛型

集合类

到目前为止，Java 类库中泛型支持存在最多的地方就是集合框架。就像容器类是 C++ 语言中模板的主要动机一样（参阅 附录 A：与 C++ 模板的比较）（尽管它们随后用于很多别的用途），改善集合类的类型安全是 Java 语言中泛型的主要动机。集合类也充当如何使用泛型的模型，因为它们演示了泛型的几乎所有的标准技巧和方言。

所有的标准集合接口都是泛型化的 —— Collection<V>、List<V>、Set<V> 和 Map<K,V>。类似地，集合接口的实现都是用相同类型参数泛型化的，所以 HashMap<K,V> 实现 Map<K,V> 等。

集合类也使用泛型的许多“技巧”和方言，比如上限通配符和下限通配符。例如，在接口 Collection<V> 中，addAll 方法是像下面这样定义的：

interface Collection<V> {
  boolean addAll(Collection<? extends V>);
}

该定义组合了通配符类型参数和有限制类型参数，允许您将 Collection<Integer> 的内容添加到 Collection<Number>。

如果类库将 addAll() 定义为接受 Collection<V>，您就不能将 Collection<Integer> 的内容添加到 Collection<Number>。不是限制 addAll() 的参数是一个与您将要添加到的集合包含相同类型的集合，而有可能建立一个更合理的约束，即传递给 addAll() 的集合的元素 适合于添加到您的集合。有限制类型允许您这样做，并且使用有限制通配符使您不需要使用另一个不会用在其他任何地方的占位符名称。

应该可以将 addAll() 的类型参数定义为 Collection<V>。但是，这不但没什么用，而且还会改变 Collection 接口的语义，因为泛型版本的语义将会不同于非泛型版本的语义。这阐述了泛型化一个现有的类要比定义一个新的泛型类难得多，因为您必须注意不要更改类的语义或者破坏现有的非泛型代码。

作为泛型化一个类（如果不小心的话）如何会更改其语义的一个更加微妙的例子，注意 Collection.removeAll() 的参数的类型是 Collection<?>，而不是 Collection<? extends V>。这是因为传递混合类型的集合给 removeAll() 是可接受的，并且更加限制地定义 removeAll 将会更改方法的语义和有用性。

其他容器类

除了集合类之外，Java 类库中还有几个其他的类也充当值的容器。这些类包括 WeakReference、SoftReference 和 ThreadLocal。它们都已经在其包含的值的类型上泛型化了，所以 WeakReference<T> 是对 T 类型的对象的弱引用，ThreadLocal<T> 则是到 T 类型的线程局部变量的句柄。

泛型不止用于容器

泛型最常见最直观的使用是容器类，比如集合类或引用类（比如 WeakReference<T>）。Collection<V> 中类型参数的含义很明显 —— “一个所有值都是 V 类型的集合”。类似地，ThreadLocal<T> 也有一个明显的解释 —— “一个其类型是 T 的线程局部变量”。但是，泛型规格说明中没有指定容积。

像 Comparable<T> 或 Class<T> 这样的类中类型参数的含义更加微妙。有时，就像 Class<T> 中一样，类型变量主要是帮助编译器进行类型推理。有时，就像隐含的 Enum<E extends Enum<E>> 中一样，类型变量只是在类层次结构上加一个约束。

Comparable<T>

Comparable 接口已经泛型化了，所以实现 Comparable 的对象声明它可以与什么类型进行比较。（通常，这是对象本身的类型，但是有时也可能是父类。）

public interface Comparable<T> {
  public boolean compareTo(T other);
}

所以 Comparable 接口包含一个类型参数 T，该参数是一个实现 Comparable 的类可以与之比较的对象的类型。这意味着如果定义一个实现 Comparable 的类，比如 String，就必须不仅声明类支持比较，还要声明它可与什么比较（通常是与它本身比较）：

public class String implements Comparable<String> { ... }

现在来考虑一个二元 max() 方法的实现。您想要接受两个相同类型的参数，二者都是 Comparable，并且相互之间是 Comparable。幸运的是，如果使用泛型方法和有限制类型参数的话，这相当直观：

public static <T extends Comparable<T>> T max(T t1, T t2) {
  if (t1.compareTo(t2) > 0)
    return t1;
  else
    return t2;
}

在本例中，您定义了一个泛型方法，在类型 T 上泛型化，您约束该类型扩展（实现） Comparable<T>。两个参数都必须是 T 类型，这表示它们是相同类型，支持比较，并且相互可比较。容易！

更好的是，编译器将使用类型推理来确定当调用 max() 时 T 的值表示什么意思。所以根本不用指定 T，下面的调用就能工作：

String s = max("moo", "bark");

编译器将计算出 T 的预定值是 String，因此它将进行编译和类型检查。但是如果您试图用不实现 Comparable<X> 的 类 X 的参数调用 max()，那么编译器将不允许这样做。

Class<T>

类 Class 已经泛型化了，但是很多人一开始都感觉其泛型化的方式很混乱。Class<T> 中类型参数 T 的含义是什么？事实证明它是所引用的类接口。怎么会是这样的呢？那是一个循环推理？如果不是的话，为什么这样定义它？

在以前的 JDK 中，Class.newInstance() 方法的定义返回 Object，您很可能要将该返回类型强制转换为另一种类型：

class Class {
  Object newInstance();
}

但是使用泛型，您定义 Class.newInstance() 方法具有一个更加特定的返回类型：

class Class<T> {
  T newInstance();
}

如何创建一个 Class<T> 类型的实例？就像使用非泛型代码一样，有两种方式：调用方法 Class.forName() 或者使用类常量 X.class。Class.forName() 被定义为返回 Class<?>。另一方面，类常量 X.class 被定义为具有类型 Class<X>，所以 String.class 是 Class<String> 类型的。

让 Foo.class 是 Class<Foo> 类型的有什么好处？大的好处是，通过类型推理的魔力，可以提高使用反射的代码的类型安全。另外，还不需要将 Foo.class.newInstance() 强制类型转换为 Foo。

考虑一个方法，它从数据库检索一组对象，并返回 JavaBeans 对象的一个集合。您通过反射来实例化和初始化创建的对象，但是这并不意味着类型安全必须完全被抛至脑后。考虑下面这个方法：

public static<T> List<T> getRecords(Class<T> c, Selector s) {
  // Use Selector to select rows
  List<T> list = new ArrayList<T>();
  for (/* iterate over results */) {
    T row = c.newInstance();
    // use reflection to set fields from result
    list.add(row); 
  }
  return list;
}

可以像下面这样简单地调用该方法：

List<FooRecord> l = getRecords(FooRecord.class, fooSelector);

编译器将会根据 FooRecord.class 是 Class<FooRecord> 类型的这一事实，推断 getRecords() 的返回类型。您使用类常量来构造新的实例并提供编译器在类型检查中要用到的类型信息。

用 Class<T> 替换 T[]

Collection 接口包含一个方法，用于将集合的内容复制到一个调用者指定类型的数组中：

public Object[] toArray(Object[] prototypeArray) { ... }

toArray(Object[]) 的语义是，如果传递的数组足够大，就会使用它来保存结果，否则，就会使用反射分配一个相同类型的新数组。一般来说，单独传递一个数组作为参数来提供想要的返回类型是一个小技巧，但是在引入泛型之前，这是与方法交流类型信息最方便的方式。

有了泛型，就可以用一种更加直观的方式来做这件事。不像上面这样定义 toArray()，泛型 toArray() 可能看起来像下面这样：

public<T> T[] toArray(Class<T> returnType)

调用这样一个 toArray() 方法很简单：

FooBar[] fba = something.toArray(FooBar.class);

Collection 接口还没有改变为使用该技术，因为这会破坏许多现有的集合实现。但是如果使用泛型从新构建 Collection，则当然会使用该方言来指定它想要返回值是哪种类型。

Enum<E>

JDK 5.0 中 Java 语言另一个增加的特性是枚举。当您使用 enum 关键字声明一个枚举时，编译器就会在内部为您生成一个类，用于扩展 Enum 并为枚举的每个值声明静态实例。所以如果您说：

public enum Suit {HEART, DIAMOND, CLUB, SPADE};

编译器就会在内部生成一个叫做 Suit 的类，该类扩展 java.lang.Enum<Suit> 并具有叫做 HEART、DIAMOND、CLUB 和 SPADE 的常量（public static final）成员，每个成员都是 Suit 类。

与 Class 一样，Enum 也是一个泛型类。但是与 Class 不同，它的签名稍微更复杂一些：

class Enum<E extends Enum<E>> { . . . }

这究竟是什么意思？这难道不会导致无限递归？

我们逐步来分析。类型参数 E 用于 Enum 的各种方法中，比如 compareTo() 或 getDeclaringClass()。为了这些方法的类型安全，Enum 类必须在枚举的类上泛型化。

所以 extends Enum<E> 部分如何理解？该部分又具有两个部分。第一部分指出，作为 Enum 的类型参数的类本身必须是 Enum 的子类型，所以您不能声明一个类 X 扩展 Enum<Integer>。第二部分指出，任何扩展 Enum 的类必须传递它本身 作为类型参数。您不能声明 X 扩展 Enum<Y>，即使 Y 扩展 Enum。

总之，Enum 是一个参数化的类型，只可以为它的子类型实例化，并且这些子类型然后将根据子类型来继承方法。幸运的是，在 Enum 情况下，编译器为您做这些工作，一切都很好。

与非泛型代码相互操作

数百万行现有代码使用已经泛型化的 Java 类库中的类，比如集合框架、Class 和 ThreadLocal。JDK 5.0 中的改进不要破坏所有这些代码是很重要的，所以编译器允许您在不指定其类型参数的情况下使用泛型类。

当然，以“旧方式”做事没有新方式安全，因为忽略了编译器准备提供的类型安全。如果您试图将 List<String> 传递给一个接受 List 的方法，它将能够工作，但是编译器将会发出一个可能丧失类型安全的警告，即所谓的“unchecked conversion（不检查转换）”警告。

没有类型参数的泛型，比如声明为 List 类型而不是 List<Something> 类型的变量，叫做原始类型。原始类型与参数化类型的任何实例化是赋值兼容的，但是这样的赋值会生成 unchecked-conversion 警告。

为了消除一些 unchecked-conversion 警告，假设您不准备泛型化所有的代码，您可以使用通配符类型参数。使用 List<?> 而不使用 List。List 是原始类型；List<?> 是具有未知类型参数的泛型。编译器将以不同的方式对待它们，并很可能发出更少的警告。

无论在哪种情况下，编译器在生成字节码时都会生成强制类型转换，所以生成的字节码在每种情况下都不会比没有泛型时更不安全。如果您设法通过使用原始类型或类文件来破坏类型安全，就会得到与不使用泛型时得到的相同的 ClassCastException 或 ArrayStoreException。

已检查集合

作为从原始集合类型迁移到泛型集合类型的帮助，集合框架添加了一些新的集合包装器，以便为一些类型安全 bug 提供早期警告。就像 Collections.unmodifiableSet() 工厂方法用一个不允许任何修改的 Set 包装一个现有 Set 一样，Collections.checkedSet()（以及 checkedList() 和 checkedMap()）工厂方法创建一个包装器（或者视图）类，以防止您将错误类型的变量放在集合中。

checkedXxx() 方法都接受一个类常量作为参数，所以它们可以（在运行时）检查这些修改是允许的。典型的实现可能像下面这样：

public class Collections { 
  public static <E> Collection<E> checkedCollection(Collection<E> c, Class<E> type ) {
    return new CheckedCollection<E>(c, type);
  }

  private static class CheckedCollection<E> implements Collection<E> {
    private final Collection<E> c;
    private final Class<E> type;

    CheckedCollection(Collection<E> c, Class<E> type) {
      this.c = c;
      this.type = type;
    }

    public boolean add(E o) {
      if (!type.isInstance(o))
        throw new ClassCastException();
      else
        return c.add(o);
    }
  }
} 

五 底层细节

擦除

也许泛型最具挑战性的方面是擦除（erasure），这是 Java 语言中泛型实现的底层技术。擦除意味着编译器在生成类文件时基本上会抛开参数化类的大量类型信息。编译器用它的强制类型转换生成代码，就像程序员在泛型出现之前手工所做的一样。区别在于，编译器开始已经验证了大量如果没有泛型就不会验证的类型安全约束。

通过擦除实现泛型的含意是很重要的，并且初看也是混乱的。尽管不能将 List<Integer> 赋给 List<Number>，因为它们是不同的类型，但是 List<Integer> 和 List<Number> 类型的变量是相同的类！要明白这一点，请评价下面的代码：

new List<Number>().getClass() == new List<Integer>().getClass()

编译器只为 List 生成一个类。当生成了 List 的字节码时，将很少剩下其类型参数的的跟踪。

当生成泛型类的字节码时，编译器用类型参数的擦除 替换类型参数。对于无限制类型参数（<V>），它的擦除是 Object。对于上限类型参数（<K extends Comparable<K>>），它的擦除是其上限（在本例中是 Comparable）的擦除。对于具有多个限制的类型参数，使用其最左限制的擦除。

如果检查生成的字节码，您无法说出 List<Integer> 和 List<String> 的代码之间的区别。类型限制 T 在字节码中被 T 的上限所取代，该上限一般是 Object。

多重限制

一个类型参数可以具有多个限制。当您想要约束一个类型参数比如说同时为 Comparable 和 Serializable 时，这将很有用。多重限制的语法是用“与”符号分隔限制：

class C<T extends Comparable<? super T> & Serializable>

通配符类型可以具有单个限制 —— 上限或者下限。一个指定的类型参数可以具有一个或多个上限。具有多重限制的类型参数可以用于访问它的每个限制的方法和域。

类型形参和类型实参

在参数化类的定义中，占位符名称（比如 Collection<V> 中的 V）叫做类型形参（type parameter），它们类似于方法定义中的形式参数。在参数化类的变量的声明中，声明中指定的类型值叫做类型实参（type argument），它们类似于方法调用中的实际参数。但是实际中二者一般都通称为“类型参数”。所以给出定义：

interface Collection<V> { ... }

和声明：

Collection<String> cs = new HashSet<String>();

那么，名称 V（它可用于整个 Collection 接口体内）叫做一个类型形参。在 cs 的声明中，String 的两次使用都是类型实参（一次用于 Collection<V>，另一次用于 HashSet<V>）。

关于何时可以使用类型形参，存在一些限制。大多数时候，可以在能够使用实际类型定义的任何地方使用类型形参。但是有例外情况。不能使用它们创建对象或数组，并且不能将它们用于静态上下文中或者处理异常的上下文中。还不能将它们用作父类型（class Foo<T> extends T），不能用于 instanceof 表达式中，不能用作类常量。

类似地，关于可以使用哪些类型作为类型实参，也存在一些限制。类型实参必须是引用类型（不是基本类型）、通配符、类型参数，或者其他参数化类型的实例化。所以您可以定义 List<String>（引用类型）、List<?>（通配符）或者 List<List<?>>（其他参数化类型的实例化）。在带有类型形参 T 的参数化类型的定义中，您也可以声明 List<T>（类型形参）。

六 结束语

泛型的引入是对 Java 语言和 Java 类库的一个主要改变。泛型可以提高 Java 应用程序的类型安全、可维护性和可靠性，代价是一些附加的复杂性。

已经做了非常小心的处理，以确保现有的类将继续与 JDK 5.0 中的泛型化类库一起工作，所以您可以根据自己的意愿选择从什么时候开始使用泛型。

2005年5月标记着自从Sun第一个引入Java技术以来经历了整整10个年头。在过去的10年中，Java语言已经变为一个平台，一个社团和一个生态系统。在这些环境下，软件用户、开源工程以及个体开发者等茁壮成长。今天，大约有四百五十万Java开发者和大约1.4亿台设备上使用着Java。

我们不空谈Java的成功故事。代替的是通过分发调查问卷（每发展一年提问一个问题）来搜集个人的Java使用经验，这些人大都是精于Java技术的开发者。回答者包括各个层面的人，从咨询师、作家到BEA、IBM、Sun等大公司的CTO和资深技术人员。

下面是一些我们收到的令人瞠目的回答。

1. 你是如何开始使用Java编程的？

Java吸引了每个人的注意，从程序开发人员到……

当Java还称为Oak的时候我就用它进行编程，大约是在1993年的下半年或者是1994年的上半年。当时我在Sun Labs率领一个研究小组。一旦我们使用Java开发，我们就注意到使用Java的最大优点是，它能以一种合理的安全的方式从一个虚拟机迁移到另一台虚拟机。，这是Jim Waldo（SunLabs的杰出工程师）的回答。

Rod Smith，作为IBM软件开发小组中处理突发技术的副主席，写道：我们看到了，Java平台是一种足够好的技术，它具有在计算机工业界成为一支重大的独成系列的力量的潜力。我们认为，我们最好要赶上这班时代列车并采纳Sun的Java技术而不再依赖于以前的模式-自己开发每一件东西。

Ed Cobb，BEA Systems公司CTO办公室架构标准的副主席，写道：我们可以选择其它主流的面向对象语言，但是Java提供了一种更好的组合特点使它适合于团队环境下的大规模开发。

在过去十年中的大部分时间里，我受雇于Sun。因此，我不得不说，Java突然来到我的身边。如果不是这一突然性的到来，我们也会需要另外一种似Java的东西来叩开业界中正迅速发展的网络计算环境的大门。-Rob Gingell，Cassatt Corporation的执行副主席和CTO。

...对那些勤奋的计算机系的大学生们...

Michael Pilone，作为Blueprint Technologies的资深软件工程师，他的回答是：当时我盘算着我将来得找一份体面的工作，所以虽然我在大学中所学全部是C++，但是我还是另外自学了Java。

在我上硕士期间，我的指导教授让我用Java工作，结果我用Java 1.0 beta版完成了我所有的功课。-Raghu Donepudi，环球计算机公司的系统开发领导者。

...对那些热衷于编程的狂热者...

我一毕业即用Java开始工作，我惊喜于Java的WORA的前景和Applets。-Jack Herrington,作为Code Generation in Action (Manning)的作者和Code Generation Network的编辑。

我甚至在1.0版本之前就开始学习Java了，因为其开发目标是作为微软工具（VB和Visual C++）与Pascal语言的可选替代者，Laurent Ploix写道，他是SunGard-Finance公司的工程总管和技术架构师。

在1997年，我带着一本手册作为度假读物，在海滩度假的日子里，我沉浸在Java的优美之中。我转向了Java，并宣布C++是一种传统的语言，并发誓一旦选择了Java，永不回头。-Vlad Patryshev,Borland公司Java Business Unit的前任R&D工程师。

2.Java宣称的编写一次，到处运行效果怎么样（WORA）？一直以来，WORA的重要性改变了多少？

Java虚拟机，至少在概念上，是Java背后最强有力的思想。它的确实现了它许诺的轻便性。-Bruce Tate，J2Life, LLC（一家Java技术咨询公司）的主席。

应用服务器和J2EE应用程序可以在多种平台上良好地迁移。我认为在客户端上实现WORA还是相当值得怀疑的，也许永远不会实现。-Michael Pilone

它对我简直是一个不可捉摸的平台。-Vlad Patryshev

Java的早期成功根本上在于WORA。与其它可选择工具相比，Java带给了（并将进一步带给）SI（系统集成商），ISV（独立软件开发商）和软件工程师们一个根本不同的经济环境。-Rod Smith

Java在WORA方面的性能：a)比任何它之前的工具要好；b)就目前而言，与另外一些可选工具相比仍然要好得多；c)将作为Java价值的一个关键部分继续保持下去。-Rob Gingell

WORA每次都带给我极大的便利。我总是在Windows平台上进行我的Java开发；但是，我总是毫不费劲地把这些代码发布到Solaris 或者Linux 环境中去。-Eric Bruno，一个独立的咨询师，擅长于软件架构，企业Java和C++开发。

你可以把字节代码转换成MSIL（MS中间语言），而且你可以在J#中运行Java程序。这使我们可以针对我们产品的Java和.NET环境只保留一份代码即可。-Michael R. Smialek，Knowledge Dynamics的主席和CEO

我经常跨Windows，Linux和Sun Solaris开发，测试和发布Java代码，而仅需对XML配置文件作较少的改动。但是，随着面向服务的结构的出现，WORA的重要性已经减弱了。-Kyle Gabhart，作家和独立咨询师

象Perl，Ruby和Python等语言一样轻便。-Jack Herrington

一些人认为，由于通用操作系统的数目的下降，WORA将变得不再如以前那么重要。事实上，即使只有两种合理的可能的目标平台存在，WORA就一直是重要的。-Ed Cobb

二、客户端Java及开发工具选择

3.你用Java编写过多少代码？估计你将来的工作有多少会用Java实现？

几乎所的的回答者声称Java是他们主要的产品编码工具，大多数人选择他们的Java使用率超过70%。没有人认为他们下一步的Java开发使用率会降低。

去年，我们利用Java 技术开发出了800多个商业产品。几乎我们所有的中间件都依赖于Java运行时刻库。-IBM的Rod Smith

在我们的顾客中，我们仍看到具有可以预料的潜在需求的大量C/C++功能第一型的应用程序。他们经常愿意用Java进行开发，而Java虚拟机技术目前正发展到正好能够处理这些类型系统的时候。

在Web应用程序开发中，我想，当人们的应用程序变得越来越大且越复杂时，我们将看到针对动态类型语言会出现一点后推力作用。他们将经受运行时刻类型异常--事实上，他们早已认识到，如果采用象Java一样的强类型语言的话，这是可以避免的。-BEA公司的Ed Cobb

4.你用Java开发桌面应用和服务器应用的比例为多少？如果你开发过桌面应用程序，你更喜欢用SWT还是Swing，为什么？

Bruce Tate对这一问题的回答总结了所有其他人的观点：服务器端Java正是它应有的位置。

至于，客户端Java开发，众说纷纭...

Swing太复杂，太不可预测，太难学。SWT则好一些，但一般而言，Java在用户接口设计上很不成功。-Tate，《Better, Faster, Lighter Java》和《Bitter Java》的作者

我认为SWT有更好的方法，它链接到本地lib库文件以达到加快速度和一致性的目的，但是我并不喜欢这些API，因为它们暴露出太多的老式的编码技术。相比之下，Swing有一个更好些的API，但是其中充满错误、性能低下且设计糟糕。-Michael Pilone

我更喜欢SWT...它比Swing更具本地化，Swing而可以说只是粗略地实现了本地化。-Ed Cobb

我写Swing应用程序，然后使用Java Web Start来进行发布。我还没有出卖过我的SWT型程序，因为它仅有有限的跨平台支持并缺乏可靠的MVC设计。-Kyle Gabhart

5.你使用的Java开发环境是什么？

很明显，当前流行的Eclipse框架和集成开发环境是大多数对这一问题的回答，因为其是Windows和Linux平台的主流环境。只有另外少数的回答者指定了其它几个选择：

我选择的平台是WinXP Pro。在安装了Cygwin和另外几个开发工具后，你就可以得到一个具有硬件支持的非常有用的系统了。-Michael Pilone

我特别喜欢J2SE 5。说到IDE，我更喜欢Jbuilder，其次是IDEA。IDEA中有一些巧妙的实现，但是良好的经典的Jbuilder具有我需要的任何东西。-Vlad Patryshev

我一直使用emacs开发而用println进行调试。最近我在使用NetBeans，已惊奇于它给我带来的巨大帮助。-Jim Waldo

请不要使用EJB！-Laurent Ploix

Café。-Smialek

在必要的时候，我都使用vi进行开发。-Kyle Gabhart

三、开源，JCP和对Java的希望列举

6.JCP和开源社群谁在Java更新上的贡献更大？

到目前为止，应该说是开源的贡献更大。而JCP在进行实际的开发实践之前，推崇标准化的作用。EJB,日志以及持久性一直是JCP中的灾难。实际上JCP在抛弃着Java的根基。很难的问题在拐弯抹角变得易于解决，而容易的问题反而在变得越来越难于解决了。-Bruce Tate

开放源码的执行领导着开发过程，而JCP仅仅是定义了一些标准。-Laurent Ploix

如果说纯粹的革新，我将选择开源。当工程中存在漏洞需要补全时，开源是能够迅速得到响应的。而JCP目前是一种太慢的方式，以至于根本跟不上工业发展的步伐。-Michael Pilone

多数的革新经历了JCP模式。但是，在过去的几年中，我们看到了在开源模式中的活动不断增加的迹象。-Rod Smith (IBM)

为使得开源运动进行下去，JCP值得广泛的信任，它对于Java生态系统的发展起到提供一个群落中心的作用。任何一些非JCP标准的开源工程已经探索了各式各样的思想-一些是糟糕的，一些却取得了令人惊喜的成绩。JCP可以说是一场伟大的创新运动的火车头。-Ed Cobb (BEA)

JCP本身仅仅是定义了一些标准及相应的说明书，这在已有的工程实现中被得到支持。作为编程者，我们不想根据一段现成的Java编码来指导我们编程，而要根据一套成熟的说明书进行开发。真正有用的编程最开始往往是零碎的代码片断，经常经历一个先有代码然后有规范的说明书的过程。-Rob Gingell

我找到了开源的主动性，特别是从Apache到当前最具创新性的有用的软件中找到的。-Eric Bruno

7.Sun应该开放Java的源代码吗？

你知道这个问题肯定会出现在问卷之中的。

这一点并不重要。Java在走自己路的过程中，自身已经建设得足够强大。-Bruce Tate

如果Sun在做这样一件有益的工作，为什么要打扰他呢？-Raghu Donepudi

不应该。如果它实现开源，那么我们能够看到Java的许多技巧，这最终将导致一些问题的出现，例如我们现在使用应用程序服务器时所遇到的问题。-Rahul Kumar Gupta

是的。Sun拒绝这样做的唯一原因就是，Java完全是他们自己的产品，他们使用它来使自己的公司得以维持下去。-Jack Herrington

一方面，开源的思想是很有吸引力的，因为它将导致更多的错误在很短的时间内就得以修改。另一方面，它可能导致分支分派的不匹配的JAVA虚拟机的出现。-Michael Pilone

不。我不相信一群普普通通的所谓天才人物就能取代那些负责管理极为健全的基本概念的大家们的科学思想-其中的大多数人甚至还不能明白这个问题。-Vlad Patryshev

开源社团的加入将会加速创新并推动该平台的竞争性。-Rod Smith(IBM)

我们需要一个开源Java的主要原因是确保该平台的生命力。如果将来Sun公司发生什么事情的话，开源的Java将列入我们的保险计划中。-Ed Cobb(BEA)

我认为是应该的。‘开源’Java并不要求Sun做什么事情，它只是要求另外一些公司或个人做一些事情。‘开源’Java是不可避免的。我建议Sun积极地实现这一不可避免并为此带来的益处做一些工作。-Rob Gingell

我对此并不关心-Kyle Gabhart

8.你希望Java有怎样的改进？

从较低层次上，Java需要代码的模块化，扩展和一个更具动态化的模型，以及还需要增加很多的功能以使得应用程序开发更为容易，因为你不可能仅仅利用库来实现一切。-Bruce Tate

内省机制（用一个类来分析JavaBean的特性）使用起来太难且过于繁重。-Laurent Ploix

需要加入代码使用许可证机制。-Greg Magnusson，Cyborg Spiders的Web技术开发的奠基者

应该提供由开发者来进行内存管理的功能。-Raghu Donepudi

应该加入运算符重载功能。-Jack Herrington

目前迫切需要在Java中加入Jar版本机制。我记不清有多少次遇到XML分析库冲突或者日志库冲突了。-Michael Pilone

类对象。十年了，没有任何改变。有大量的类对象需要加上去。-Vlad Patryshev

Java平台目前已经变得过于复杂。我们认为Java社团需要做出更好的工作来满足独立的和中小型的商业需要，这也是为了Java继续发展、繁荣和成功的目的。-Rod Smith（IBM）

Java非常需要一个更为强壮的模块化的系统。当前，我们所拥有的是一些.jar文件，其结果是成了‘.jar文件地狱’。但是今天还很难描述一个互有联系的模块化的系统。-Ed Cobb

我原先希望Java能够实现的，过去的Java并没有做到：关于日期和时间问题上有好几处从一开始就是错误的；RMI/IIOP的引入在理论上是正确的但完全没有必要；它自一开始就是自我封闭的。-Rob Gingell

对于类的加载和对象的Java运行时刻类型的关系的处理是一个错误，现在我们还在为之付出代价。你不可能真正确定出是否你的程序在编译时刻是类型安全的。而且，如果你在做适当动态的任何操作，你经常需要对一个给定类的正确加载作出猜测分析。-Jim Waldo

垃圾回收简直是个噩梦。它有可能使得没有经过良好训练的，懒散的编程人员进入到这个工业领域中。

Java需要增加的另外一些功能有：操作符重载；预编译指令（#define，等等）；把声明与定义（头文件和源文件）相分离的能力；唯一的、非本机的机器标志符（用于认证之目的）。-Michael Smialek

迫切需要加入Code-Behind（页面代码分离）技术！！！ASP.NET和页面代码分离技术所带来的重用性与灵活性是巨大的。我希望JSP 3.0能够朝这个方向发展。-Kyle Gabhart

我更愿意使用Java对象来存取操作系统而不是用JNI（Java本机接口），因为大多数的Win32/Linux API都包含在Java中了。-Alexi Jordanov，OSGi技术公司ProSyst Bulgaria的项目领导者

四、Java带给人们的最伟大的礼物与Java的未来

9.Java对软件社群最大的贡献是什么？

我们收到的大部分反映结果认为是平台独立性，Java平台和该语言本身的创建以及他们创建的各种社团。

有两点：它使得更广泛的用户群可以接受垃圾收集语言；围绕该语言涌现出了各种集成开发环境。-Jack Herrington

Java真正地震撼了许多东西，这包括迫使微软设计出新的产品，诸如Visual Studio的进一步改进和.NET产品的出现等。由于Netscape选择了Java,这使得客户浏览器能够执行JavaScript。它使当今世界服务器端开发也迈出了巨大的一步，受此技术影响的站点数以百万计。-Michael Pilone

数百万的学生不需要学习C++。-Rob Gingell

能使多家厂商贯彻实施的标准化API的建立。很多厂家竞相提供该标准化接口的最好实现，这给业界创造高质量的解决方案带来了强大发展动力。-Kyle Gabhart

.NET-Michael Smialek

10.Java的未来会如何？

任何一种语言总是存在其有限的技术领先周期，Java也不例外。在某种意义上看，能超过Java技术会是一种非常有趣的事情。-Bruce Tate

当桌面和膝上电脑要被手持设备取代时，我们可能需要一种更简单的更强有力的语言。-Raghu Donepudi

C#具有挤垮Java的潜力，它是一种更好的语言。-Jack Herrington

微软在通过.NET以一种令人难以置信的速度发展。由于拥有Windows操作系统的大量客户端用户，所以他们比Java具有更大的优势。-Michael Pilone

在一些新技术被编程世界接受之前，至少要经过几年的时间。例如，看起来不超过5%的Java程序员能掌握Java泛型编程。请问，又有多少人可以掌握Lock/Condition？-Vladimir Patryshev

当技术朝着围绕交互性的结构化（如面向服务的结构化）方向发展的时候，Java语言将继续作为一种语言在计算机工业发展中占有重要地位。-Rod Smith

在某种意义上看，Java 虚拟机体系所要求的限制可能有点太严肃了。但是，任何一种新的挑战者虚拟机登上舞台并用之取代Java平台都是一件很好的事情。-Ed Cobb

实际上我们可以开发出许多种不同的语言，其中一些可能与我们熟知的Java根本不同，但是仍旧保持应用程序二进制接口（ABI）。这是为什么Java将会保持长时期的重要性的原因。-Rob Gingell

Java将继续作为一股巨大的力量存在于IT业中，但是一些瞄准市场的脚本语言将会在某些行业中进一步发展壮大。-Doug Tillman，Grainger.com站点Java和Python技术的开发者

任何一个人，只要他在该界业干过多年，都不会相信，存在一种技术会对要推翻自己的更新、更快或者更有效的技术产生免疫力。-Kyle Gabhart

　　Spring+Hibernate+Struts已成为Java开发的主流体系。在这个体系中，Spring+Hibernate的地位应该说短期内是难以撼动了。除了新兴的Jboss Seam作为挑战者之外，几乎难有劲敌。有趣的是当初Spring、Hibernate作为挑战者，将官方的EJB成功挑落马下;这次反倒是官方的EBJ3成了挑战者，不知结局如何。

　　Java B/S编程中历来战火最激烈的其实还在Web层，框架的数量最多，争议最大。

　　一切由Struts而起，而Struts最终也坐稳了第一个时代的王座。在技术层面，Struts 1.x已经被无数人抱怨过、批评过，但终于还是稳坐王位，这充分说明了习惯的力量。“稳定压倒一切”，这句话在IT技术领域仍旧适用。

　　其实IT应用技术，什么新鲜玩意并不难学。难的是标准化和规范化。每个程序员都有自己的思路和习惯，写出来的代码自然是五花八门。Java何以成为编程界的老大，很重要的一点在于Java的规范化。这种规范化很高的语言适用于多人合作的大型项目，便于沟通和理解，也就便于集成和维护。Java世界为什么会框架横飞，说到底还是规范化的需要。纯JSP和Struts写Web谁快，摆明了是JSP。那撑饱了用Struts?原因在于100个人写出来的JSP，有100种写法;而100个人写出来的Struts，基本相似。Struts之成功，正缘于其在Java Web层的规范化方面所做出的贡献。

　　然而长江后浪推前浪，Struts 1.x的技术缺陷毕竟是隐患。

　　Sun力推JSF，打算一雪Web层框架缺失之耻。可惜JSF既要沿用Swing的技术路线，又要学ASP.net，还要照顾产商的IDE，结果搞了个四不象，弄得里外不是人。当然Sun的技术实力毕竟是超强的，只要别重蹈EJB的覆辙，拿出点专断的精神(像这两年的NetBeans)，做出像Swing那样水准的东西，JSF当大有作为。JSF现在比较有优势的是对Ajax的集成，这一点走在了其他框架的前面。

　　而Struts就更没有志气了，把WebWork换了个标签，凑出个Struts2，Bug多多。说实在话，根本不如原版的WebWork。如果不是靠了原先的fans捧场，根本就没得混。不过Struts原本就不是以技术取胜的，靠的是抢占先机带来的习惯优势。如果原先的fans们在这两年内都能转到Struts2，那么Struts二世仍将雄霸天下。

　　综上所述，未来两年，JSF与Struts将展开Java Web框架的最终战争。

　　以笔者愚见，结局有二：一是不论Struts还是JSF获胜，Java Web层都将结束混战的局面，这对Java Web开发的标准化是非常有利的，并有助于巩固Java在B/S界的地位;二是Struts1.x、Struts2、JSF三分天下，必然从整体上削弱Java在B/S界的竞争力，并将进一步被RoR、ASP.NET、PHP所蚕食。