泛型（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所蚕食。

• Provide a list of all MIME types known to a MailcapCommandMap.
• Provide access to the native commands known to a MailcapCommandMap.
• Support for fallback entries in mailcap file.

The JavaBeans Activation Framework 1.1 requires J2SE 1.4 or greater.

The JavaBeans Activation Framework 1.1 final release is included with the Java SE 6 release and the Java EE 5 release, and is also available separately.

                     ... ...

JavaBeans Activation Framework（JAF）主页 　　 http://java.sun.com/beans/glasgow/jaf.html　

JavaBeans激活框架（JavaBeans Activation Framework）

       JAF的目的在于统一处理不同数据格式的方法（不管数据格式为简单文本还是由图片、声音、视频甚至其它"活动"内容共同组成的复合文档）。在这个意义上，JAF对Java的作用正如插件对Web浏览器的作用。JAF使得Java对象与编码数据流之间的映射变得非常容易。

       JAF完成于1998年，当时JavaBean非常流行，Swing非常热门，Servlet刚刚出现，J2EE平台还没有。那时Sun需要一个用于文件浏览器和JavaMail的标准发现API，此需要推动了JAF的创建。“发现”指可以动态找到正确的组件以处理任意但类型化了的数据的机制。特别是，作为发现API来开发JAF，以便使GUI开发人员能够为文档和图像数据动态地发现浏览器和编辑器。

       发现取决于注册的类型，注册可以将每一文件类型与对应的应用程序建立关联。

       简单的说，JAF提供了用于动态发现可视窗口部件以处理由MIME文件头描述的各种数据的架构。当用于SAAJ这样的非可视系统时，JAF可以将Java类型映射到将它们无缝转换到数据流的特殊处理程序，从而允许SAAJ将Java对象自动转换成由SwA MIME部分包含的原始数据。

1.       DataHandler 类

       JAF架构的核心是javax.activation.DataHandler类。DataHandler类定义了三个构造函数：

       Public DataHandler(DataSource ds)

       Public DataHandler(java.net.URL url)

       Public DataHandler(Object obj, String mimeType)

       当使用前两个构造函数时，数据处理会委托到DataSource接口的一个子类型，使用第三个构造函数时，数据处理委托到一个动态发现的内容处理程序并使用此处理程序。

       如果DataHandler是用DataSource对象构造的，那么它将首先试图试图将getContent()方法委托到一个DCH，如果它没有找到DCH，会返回一个从DataSource中得到的InputStream。有趣的是，DataHandler总是试图首先委托到一个DCH，即便是用DataSource创建DataHandler也是如此。

       上述说明的问题看似简单，但实际上非常重要，它说明了getContent()方法的作用。getContent()方法要返回一个表示附件的Java对象，DataSource的InputStream只作为最后一种手段来返回。从DCH中返回的对象类型取决于DCH的编码方式。

2.       DataContentHandler类

       此接口用于实现将Java对象流转换成数据流，或将数据流转换成Java对象。

       DataContentHandler类型的每一个子类(即每一个DCH)均用于自动将Java对象的专用类型转换为流，以及将流转换成Java对象。如某个DCH能够将java.awt.Image对象转换为JPEG或GIF编码流，或者进行反向转换。DCH的缺点是它们的使用范围通常受到很大的限制，每一个DCH只能讲一个对象类型转换成一种类型的数据流。

       与DCH不同，DataSource对象只处理数据流。用户要用DataSource从某种类型的资源中读数据流，并将数据流写入DataSource。，此时重点放在了流上而不是Java对象类型上。从而DataSource具有很大的通用性，其缺点为不宜于使用，因为用户直接处理的是流而不是Java对象。

3.       DataSource 类

       DataSource类拥有完成委托操作所需要的全部功能。当使用DataSource或URL参数构造DataHandler时，DataHandler要使用DataSource而不是DCH。

       JAF定义了两个标准的DataSource对象，即FileDataSource对象和URLDataSource对象。     某些DataSource实现用于动态发现它们的MIME类型。例如，FileDataSource用MIME类型注册表发现它的MIME类型。JAF中的默认MIME类型注册表是mimetypes.default文件，该文件包含在JAF二进制JAR文件中。

                   图1 Ja2EEa平台体系架构

　　J2EE提供了一个多层的端到端的应用系统架构，如图2所示。在客户端层，多种客户端可通过多种不同的协议来访问中间层的J2EE服务，在设计J2EE应用的时候，首先需要选择的就是J2EE客户端的类型，应根据用户的使用模式及应用环境的特点来选择适合的客户端类型和通信协议，如Java Applet客户端和Java Web Start客户端适合于复杂的图形用户界面，如大量的数据录入、数据统计等应用，能满足高效的用户交互需求，根据具体应用环境的不同，可选择HTTP(S)、RMI/IIOP或JNLP等通信协议。

图2 端到端的多层应用系统架构

　　在中间层，主要包括Web服务器和应用服务器。在实际部署时，它们可以运行于单一的或多个物理平台上。从可靠性和可伸缩性考虑，应该采用多个Web服务器和应用服务器。Web服务器接受从客户端发来的请求，通过JSP和Servlet技术动态生成响应的内容，JSP或Servlet可以接着调用运行于应用服务器EJB容器中的企业 JavaBean进行相应的业务处理和运算。而中间层通过标准的协议访问企业信息系统层来读取数据和调用服务。

　　总之，J2EE为我们提供了一个建立在开放和标准的技术之上、非常灵活的端到端的多层体系架构，从而满足各种不同企业应用的需求。

    先学习j2se
    要学习j2ee就要先学习j2se，刚开始学习j2se先建议不要使用IDE，然后渐渐的过渡到使用IDE开发，毕竟用它方便嘛。学习j2se推荐两本书，《java2核心技术一二卷》，《java编程思想》，《java模式》。其中《java编程思想》要研读，精读。这一段时间是基本功学习，时间会很长，也可能很短，这要看学习者自身水平而定。

    不要被IDE纠缠
    在学习java和j2ee过程中，你会遇到五花八门的IDE，不要被他们迷惑，学JAVA的时候，要学语言本身的东西，不要太在意IDE的附加功能，JAVA编程在不同IDE之间的转换是很容易的，过于的在意IDE的功能反而容易耽误对语言本身的理解。目前流行的IDE有jbuilder，eclipse和eclipse的加强版WSAD。用好其中一个就可以了，推荐从eclipse入手j2ee。因为Jbuilder更适合于写j2se程序。

    选择和学习服务器使用配置
    当你有了j2se和IDE的经验时，可以开始j2ee的学习了，web服务器：tomcat，勿庸置疑，tomcat为学习web服务首选。而应用服务器目前主要有三个：jboss、weblogic、websphere。有很多项目开始采用jboss，并且有大量的公司开始做websphere或weblogic向jboss应用服务器的移植（节省成本），这里要说的是，学习tomcat和jboss我认为是首选，也是最容易上手的。学习服务器使用配置最好去询问有经验的人（有条件的话），因为他们或许一句话就能解决问题，你自己上网摸索可能要一两天（我就干过这种傻事），我们应该把主要时间放在学习原理和理论上，一项特定技术的使用永远代替不了一个人的知识和学问。

    学习web知识
    如果你是在做电子商务网站等时，你可能要充当几个角色，这是你还要学习：html，可能要用到dreamwave等IDE。Javascript，学会简单的数据校验，数据联动显示等等

    J2EE API学习
    学习j2EE API和学习服务器应该是一个迭代的过程。
    先学习jsp和servlet编程，这方面的书很多，我建立看oreilly公司的两本  《jsp设计》和      《java servlet编程》，oreilly出的书总是那本优秀，不得不佩服。
    学习jdbc数据库编程，j2EE项目大多都是MIS系统，访问数据库是核心。这本应属于j2se学习中，这里拿出来强调一下。
    学习JNDI API，它和学习ejb可以结合起来。
    学习EJB API，推荐书《精通ejb》
    经过上面的这些的学习，大概可以对付一般的应用了。
    有人说跟着sun公司的《j2ee tutorial》一路学下来，当然也可以。

    学习ejb设计模式和看代码（最重要）
    设计模式是练内功，其重要性可以这么说吧，如果你不会用设计模式的话，你将写出一堆使用了ejb的垃圾，有慢又是一堆bug，其结果不如不用ejb实现（ejb不等于j2ee）
    无论学习什么语言，都应该看大量代码，你看的代码量不到一定数量，是学不好j2ee的
    目前有很多开源的工程可以作为教材：
    jive论坛
    petstore sun公司
    dune sun公司
    等等，研读一个，并把它用到自己的工程中来。

    J2EE 其他学习
    当你渐渐对j2ee了解到一定深度时，你要开始关注当前领域中的一些技术变化，J2ee是一块百家争鸣的领域，大家都在这里提出自己的解决方案，例如structs，hiberate，ofbiz等等，学习这些东西要你的项目和目标而定，预先补充一下未尝不可，但不用涉及太深，毕竟学习原理和理论是最最重要的事。

目前常见j2eeAPI
JavaServer Pages(JSP)技术1.2
Java Servlet技术2.3
JDBC API 2.0
Java XML处理API(JAXP)1.1
Enterprise JavaBeans技术2.0
Java消息服务(JMS)1.0
Java命名目录接口(JNDI)1.2
Java事务API(JTA) 1.0
JavaMail API 1.2
JavaBeans激活架构(JAF)1.0
J2EE连接器体系结构(JCA)1.0
Java认证和授权服务(JAAS)1.0 

   学习上面的某些API要以你的项目而定，了解所有他们总之是有好处的
  上面印证了大家说的一句话，java语言本身不难学，但是技术太多，所以学java很费劲。回想一下，基本上每个初学者，在刚学习java的时候可能都会问别人这么一句话，你怎么知道的哪个方法(api)在哪个包里的？呵呵，无他，唯手熟尔。

作者：IT168 IT168 卒

随着Eclipse IDE的出现和不断发展，Java社区又进入了一个新的春天，Eclipse强大而又灵活扩展的插件机制成为了吸引开发人员的天堂，使其成为一款优秀的IDE。Eclipse项目的初衷并不打算构建成一个胖客户端平台(RCP)，而只是想构建一个集成开发工具的平台。Eclipse RCP始于Eclipse2.1版本，到了3.0版本的时候，Eclipse作为一个RCP迈出了巨大的一步， 在3.0后的版本，Eclipse项目小组废除了以前的插件管理模型，通过引入OSGi(Open Service Gateway Initiative) R4标准来实现插件的动态安装，移除和更新，这使Eclipse IDE实现了革命性的变革。Eclipse3.1版本正式的引入了RCP发布功能，一时间RCP技术成为Java开发人员中最流行的词汇，那究竟什么是Eclipse RCP呢？

    什么是Eclipse RCP？

    Eclipse RCP （Rich Client Platform）是基于Eclipse项目的一个开发胖客户端应用程序的框架，它提供了一个通用的 Eclipse 工作台，允许开发人员扩展和构造强大的，跨平台应用程序。

    RCP和Plug-in工程的差别并不大，插件项目使用的工作台是Eclipse IDE本身；对于构建RCP项目，开发人员可以定义应用程序外观，商标和其它Eclipse基础组件等，实现自己的桌面应用程序。

    作者最开始接触到RCP的时候并没有感觉到RCP的强大之处，只觉得用RCP开发出来的应用程序的界面比用Swing开发出来的应用程序界面漂亮许多。但随着需求变得复杂，需要实现更多的功能，RCP的易开发性和强大的插件管理功能就显得越来越突出，真正有一种做产品的感觉，着实让人兴奋。事实上使用RCP开发的产品很多，如IBM Lotus Workspace, Eclipse trader, NASA Maestro，而Eclipse3.1本身就是使用RCP开发出的杰出代表产品。

    Web和Eclipse RCP技术孰优孰劣？

    随着RCP的强势出现，许多开发人员自然会拿Eclipse RCP技术和现在流行的Web技术对比，孰优孰劣？如果撇开业务需求，单单要对比两种技术是困难的，我们就主要对比两种技术如何适应业务的需求变化。

    Web技术的出现,不仅为Internet的广泛普及起到关键性的作用,而且还在Intranet、电子商务等其他相关计算机网络应用技术发展中起到关键作用,特别是Web动态技术.例如J2EE平台的Servlet技术,Servlet容器会将来自于客户端的HTTP请求封装为一个HttpServletRequest对象，然后根据请求的URI和servlet的键值关系，调用相应的servlet处理；最后，将处理的结果转换成HTTP响应发送回客户端。

    系统的所有业务逻辑都放在服务器端了，用户无须安装客户端程序，只需要通过浏览器就能访问，这样用户方就变成了“瘦”客户端。这种模式很好的适应了业务的变化，对于业务的改变都发生在服务器端，而客户端没有任何影响，这就是Web技术现在非常流行的重要原因之一。

    不能适应快速的业务变化，就成了传统的基于C/S模式的RCP系统最大弊端。

    Eclipse RCP的插件机制是其最大的亮点，基于Eclipse RCP构建的应用系统的表现出相当出色的扩展性，用户只需要下载一个插件，简单的部署到应用系统中，就能为应用程序添加新功能。Eclipse RCP的插件管理机制较好的解决了应用程序的扩展问题，适应业务需求的变化。

    使用RCP开发的桌面应用程序其主要应用于如科学计算，数据管理等业务领域，而Eclipse RCP与其它RCP系统相比，屏蔽了底层操作系统的差异，真正实现了跨平台；和Web应用系统相比，使用Eclipse RCP系统的开发人员还可以根据需要，实现自己的插件，部署到与有的RCP产品，增强其业务功能的。

    Web技术和RCP在各自的应用领域都扮演着非常重要的作用。这个时候可能会有人问“那Web技术会被Eclipse RCP技术取代吗”？

    Web技术会被Eclipse RCP技术取代吗？

    技术的兴起与消亡都与它关注的业务领域息息相关的，如果这种技术适合这个业务领域的发展需求，那自然会被普及推广，反之则会被淘汰。

    其实早在90年代初就提出了“Rich Client”的概念用来构造客户端应用程序，常用的开发语言有Visual Basic和Delphi，出现了大量的桌面应用程序，如ERP，财务管理系统等。而随着Internet的普及，Web技术的发展，一时间诸如CGI,ASP,JSP等技术成为了开发人员的必须要掌握的技术，越来越多的企业使用Web技术在Internet上构建应用系统，典型的系统有办公自动化系统。

    经过多年的发展，虽然有些应用开发方式已经从C/S模式演变成B/S模式，但是桌面应用程序并没有被完全被B/S系统替代，它们都在各自的业务领域中发挥着不可替代的作用，并且还不断涌现新的Web技术和RCP技术，促进各自领域的发展。如今Eclipse RCP的横空出世，备受业界关注，仿佛要打破这种平衡。

    而事实上Eclipse RCP的出现只是增强了Java领域在桌面应用的开发能力，只是Eclipse RCP优秀的插件管理机制让所有人耳目一新。我们可以理性的回过头看，当Web技术大兴其道的时候，桌面应用程序开发技术并没有消失；同样，Eclipse RCP的出现也不能够取代Web技术，两者是相互依存的关系，RCP的不断创新，将为Web2.0注入新的生机。

Log4j
Log4j是Apache的一个开放源代码项目，通过使用Log4j，我们可以控制日志信息输送的目的地是控制台、文件、GUI组件、甚至是套接口服务器、NT的事件记录器、UNIX Syslog守护进程等；用户也可以控制每一条日志的输出格式；通过定义每一条日志信息的级别，用户能够更加细致地控制日志的生成过程。这些可以通过一个配置文件来灵活地进行配置，而不需要修改程序代码。【Log4E：Log4j在Eclipse下的插件】

MonoLog
Monolog是一个用于监视和日志操作的API,国际化支持.

JTraceDump
这是工具用于保持记录程序运行期间的内容信息，并在发生错误时将其转储在一个单独的文件中（类似核心dump)。

Commons Logging
Jakarta Commons Logging (JCL)提供的是一个日志(Log)接口(interface)，同时兼顾轻量级和不依赖于具体的日志实现工具。 它提供给中间件/日志工具开发者一个简单的日志操作抽象，允许程序开发人员使用不同的具体日志实现工具。用户被假定已熟悉某种日志实现工具的更高级别的细节。JCL提供的接口，对其它一些日志工具，包括Log4J, Avalon LogKit, and JDK 1.4等，进行了简单的包装，此接口更接近于Log4J和LogKit的实现.

Lumberjack
Lumberjack为1.2 和1.3版本的JDK实现了Java日志 API（在JDK1.4中引入）。

Houston
Houston是一个开放源码的轻量级日记工具包。它提供一个插件体系使得能在底层使用成熟的日记工具如Apache log4j 与JDK1.4 Logging。

Just4Log
Just4Log 是为增强现有的日记系统（Log4j ,apache commons Logging ,JDK 1.4 Logging ）尽可能的在运行时进行配置而不需要在java源代码中进行过多的设置。

SMTPHandler  
SMTPHandler是一个java.util.logging处理器，可以通过SMTP来发送日志消息。

jLo
jLo是一个Java开源的logging框架。它有一些与其它框架不同的特性比如下：
*支持多log configurations
*当配置文件改变时可重新读取该文件*通过简单XML结构来配置jLo
*支持过滤限制日记输出等。

qflog 
qflog显示日记信息的工具。它在de.qfs.lib.log 类包上进行构建。

Simple Log
Simple Log是一个logging anti-framework.Simple Log是一个让日记操作变得简单但很小的类库并且几乎不需要你做任何操作就可以得到日记的输出.它与其它日记框架相比最大的特点是使用简单,特别是在条件配置方面.它并不打算在一个包中解决所有日记问题,但它提供足够的功能来满足大多数应用程序所需的日记操作.

LN2
LN2是一个日记处理框架.它基于模式匹配(pattern matching)的日记处理过程序.LN2在Log4J上进行松散地设计,不需要与日记级别绑定的太紧.

Log Bridge
Log Bridge允许从具体的日记实现包中提取日记.它通过提供一个扮演桥角色的简单API来实现从开发者所选择的具体日记实现包中抽取日记.Log Bridge当前支持的日记包有:
Simple Log
J2SE Logging
Log4J
IBM's Logging Toolkit for Java
jLo
Protomatter Syslog

Craftsman Spy
Craftsman Spy是一个开源的JDBC日记框架.它实现了JDBC驱动.这个日记器将记录所有SQL连接,所有批处理,所有返回的记录集,所有带参数的存储过程和执行处理所发费的时间.

log4j2me 
log4j2me是用于J2ME 平台上的log4j。当把你的代码移到J2SE/J2EE平台上时,不需要对代码进行改变，只需把log4j2me.jar替换掉log4j jar文件。与log4j所不同的是不能在j2me环境中使用log4j.properties文件来配置log4j,但可以从 JAD文件读取配置。还有其它在J2ME平台中的不同之处，log4j2me都提供了相应的解决方案。

SLF4J  
简单日记门面(Facade)SLF4J是为各种loging APIs提供一个简单统一的接口，从而使得最终用户能够在部署的时候配置自己希望的loging APIs实现。 Logging API实现既可以选择直接实现SLF4J接的loging APIs如： NLOG4J、SimpleLogger。也可以通过SLF4J提供的API实现来开发相应的适配器如Log4jLoggerAdapter、JDK14LoggerAdapter。

Logback 
Logback是由log4j创始人设计的又一个开源日记组件。logback当前分成三个模块：logback-core,logback-classic和logback-access。logback-core是其它两个模块的基础模块。logback-classic是log4j的一个改良版本。此外logback-classic完整实现SLF4J API使你可以很方便地更换成其它日记系统如log4j或JDK14 Logging。logback-access访问模块与Servlet容器集成提供通过Http来访问日记的功能。

log4javascript  
log4javascript是一个基于log4j的JavaScript日记框架。

http://www.open-open.com/29.htm

        日志系统作为服务进程存在。Windows中的的事件日志服务就属于这种类型，该类型的日志系统通常通过消息队列机制将所需要记录的日志由日志发送端发送给日志服务。日志发送端和日志保存端通常不在同一进程当中，日志的发送是异步过程。这种日志服务通常用于管理员监控各种系统服务的状态。

        日志系统作为系统调用存在。Java世界中的日志系统和Unix环境下诸多守护进程所使用的日志系统都属于这种类型。日志系统的代码作为系统调用被编译进日志发送端，日志系统的运行和业务代码的运行在同一进程空间。日志的发送多数属于同步过程。这种日志服务由于能够同步反映处系统运行状态，通常用于调试跟踪和崩溃恢复。

本文建立的日志系统基本属于第二种类型，但又有所不同。该日志系统将利用Java线程技术实现一个既能够反映统一线程空间中程序运行状态的同步日志发送过程，又能够提供快速的日志记录服务，还能够提供灵活的日志格式配置和过滤机制。

系统调试的误区
        在控制台环境上调试Java程序时，此时往控制台或者文本文件输出一段文字是查看程序运行状态最简单的做法，但这种方式并不能解决全部的问题。有时候，对于一个我们无法实时查看系统输出的系统或者一个确实需要保留我们输出信息的系统，良好的日志系统显得相当必要。

因此，不能随意的输出各种不规范的调试信息，这些随意输出的信息是不可控的，难以清除，可能为后台监控、错误排除和错误恢复带来相当大的阻力。

日志系统框架的基本功能
        一个完备的日志系统框架通常应当包括如下基本特性：

        所输出的日志拥有自己的分类。这样在调试时便于针对不同系统的不同模块进行查询，从而快速定位到发生日志事件的代码。

       日志按照某种标准分成不同级别。分级以后的日志，可以用于同一分类下的日志筛选。

       支持多线程。日志系统通常会在多线程环境中使用，特别是在Java系统当中，因此作为一种系统资源，日志系统应当保证是线程安全的。

       支持不同的记录媒介。不同的工程项目往往对日志系统的记录媒介要求不同，因此日志系统必须提供必要的开发接口，以保证能够比较容易的更换记录介质。

       高性能。日志系统通常要提供高速的日志记录功能以应对大系统下大请求流量下系统的正常运转。

       稳定性。日志系统必须是保持高度的稳定性，不能因为日志系统内部错误导致主要业务代码的崩溃。

 常用日志系统简介
在Java世界中，以下三种日志框架比较优秀：

1)        Log4J

最早的Java日志框架之一，由Apache基金会发起，提供灵活而强大的日志记录机制。但是其复杂的配置过程和内部概念往往令使用者望而却步。

2)        JDK1.4 Logging Framework

继Log4J之后，JDK标准委员会将Log4J的基本思想吸收到JDK当中，在JDK1.4中发布了第一个日志框架接口，并提供了一个简单实现。

3)        Commons Logging Framwork

该框架同样是Apache基金会项目，其出现主要是为了使得Java项目能够在Log4J和JDK1.4 l Logging Framework的使用上随意进行切换，因此该框架提供了统一的调用接口和配置方法。

mom4j 
mom4j是一个完全实现JMS1.1规范的消息中间件并且向下兼容JMS1.0与1.02.它提供了自己的消息处理存储使它独立于关系数据与语言,所以它的客户端可以用任何语言开发.

OpenJMS
OpenJMS是一个开源的Java Message Service API 1.0.2 规范的实现,它包含有以下特性：
*. 它既支持点到点（point-to-point）（PTP）模型和发布/订阅（Pub/Sub）模型。
*. 支持同步与异步消息发送
*. JDBC持久性管理使用数据库表来存储消息
*. 可视化管理界面。
*. Applet支持。
*. 能够与Jakarta Tomcat这样的Servlet容器结合。
*. 支持RMI, TCP, HTTP 与SSL协议。
*. 客户端验证
*. 提供可靠消息传输、事务和消息过滤

UberMQ
UberMQ完全实现了Java Message Service 规范。UberMQ是因为现有的许多JMS提供商已经违背了分布式计算的核心原则：快速与简单而开发的。

 
Hermes JMS
利用它提供的Swing UI可以很好的实现监控JMS providers。

 
ActiveMQ 
ActiveMQ是一个开放源码基于Apache 2.0 licenced 发布并实现了JMS 1.1。它能够与Geronimo，轻量级容器和任Java应用程序无缝的给合。

 
Somnifugi
Somnifugi使得工作在同一个java虚拟机中的线程能实现消息互发。

 
MantaRay 
MantaRay基于peer-2-peer 技术。它具有以下特性:
1.它既支持点对点(point-to-point)的域，又支持发布/订阅(publish/subscribe)类型的域。
2.并且提供对下列类型的支持：经认可的消息传递,事务型消息的传递，一致性消息和具有持久性的订阅者支持。
3.消息过滤体制。
4.能与WebLogic and WebSphere 给合。
5.支持TCP, UDP 与 HTTP传输协。

 
Presumo
Presumo也是一个实现Java Message Service API的JMS消息中间件。

 
JORAM
JORAM一个类似于openJMS分布在ObjectWeb之下的JMS消息中间件。

 
JMS4Spread
JMS4Spread是一个消息系统.它部分地实现了Java消息服务(JMS) API.

-------------------------------------------------------------------------------------------

开源JMS简单比较

我考虑在公司的项目中采用JMS来降低服务器之间的耦合性，但为了降低成本，商业软件是不考虑的，于是只能在开源的并且对商业友好的JMS服务器中选择一个了。选择条件主要基于：

支持JMS 1.1规范
持久化，能满足商业应用所需的稳定性
满足项目的性能需求
最好本身提供JNDI服务
最好支持JMX
最好本身提供一个友好的管理工具
最好提供一份完整的文档
准备进行选择的JMS服务器有：OpenJMS、UberMQ、ActiveMQ、MantaRay、JORAM

OpenJMS：老牌的JMS服务器了，也是我最早知道的开源JMS服务器，不过只支持JMS 1.02，已经很长时间没有更新了，因此不予考虑。

UberMQ：采用NIO的JMS服务器，以前我学习NIO的时候看过它的代码，写的蛮不错的，也支持JMS 1.1。由于采用了NIO，所以具有很高的弹性，在满足项目的性能需求上没有什么问题；本身也提供JNDI服务，但是遗憾的是我bind其他类型的数据时会出错；提供admin和viewer两个管理工具，但是在管理工具里不能创建ConnectionFactory和Destination并绑定到JNDI；文档不太完整；最头痛的对于持久化支持不好，如果关闭JMS服务器再开启，所有保存在JMS中的信息就全部丢失了，这点没有办法满足商业应用所需的稳定性。

ActiveMQ：最近比较活跃的一个JMS服务器，主页上的介绍说在协议配置上可以选择支持NIO，但是我仔细看它所支持的协议，却并没有提到如何配置，并且在实际的测试中也并没有发现其有采用NIO的迹象，多连接一个Client端，服务器端就增多了一个线程。满足JMS 1.1，有多种方法进行持久化；本身不提供JNDI，也没有对JMX的支持，本身不带管理工具，采用Hermes进行管理（这个我会在以后提到），文档也相对较少。

MantaRay：也是比较活跃的一个JMS服务器，采用的是P2P模型，但是我不喜欢这种模型，对于JMS服务来说，很大的一个特点就是客户端可以不用永远在线，比如在更新某一个客户端时需要暂停服务，等服务再度开启时，这段时间内所接收到的信息并不会丢失，保存在服务器上，所以我并不能看到P2P模型应用在JMS服务器上的优势，况且采用JMS服务就是为了解除耦合，速度并不是唯一需要考量的事情。出于我不喜欢其所采用模型，并且在运行其所带的示例时都出现了示例时都出现了问题，两个客户端互发互收，但是彼此之间都收不到消息，于是不予考虑。

JORAM：支持JMS 1.1，可以持久化到文件，本身提供JNDI服务和提供对JMX的支持，自带的管理工具可以添加ConnectionFactory和Destination并绑定到JNDI，这点对实现动态管理来说非常有用；文档非常完备，100多页的PDF，包含了各种配置和调整信息。其稳定性考虑的尤其好，不仅考虑到JMS服务器的集群，甚至连JNDI的集群也考虑进去（尽管暂时对我而言还用不上），这点对于商业应用而言应该会有加分。

ActiveMQ是Apache License，JORAM是LGPL，这两者对于商业应用都是友好的；UberMQ和MantaRay采用是Dual License，UberMQ的Dual License是只要你不分发，就可以允许使用；而MantaRay是商业使用需要应用一个商业的License。

比较上面的这些JMS服务器，最终我是选择了JORAM，其满足了我的绝大部分要求，唯一比较遗憾的是其采用传统的IO模型，每连接一个Client端会在服务器端增加两个线程，这点稍微影响了服务器的弹性。不过考虑到我们的项目应用，这点暂时可以不用考虑，实在压力过大了，最多到时候采用JMS集群呗：）

 
开源JMS再比较
                                      

四月份时我曾经比较了那时活跃度比较高的一些开源JMS——《开源JMS简单比较》，时隔四个月，重新回顾这些项目，发现与四个月以前的比较有一些出入，在这里再进行一些比较：）
 
比较的项目没有变化，OpenJMS、UberMQ、ActiveMQ、MantaRay、JORAM，这段时间内没有出现什么JMS新秀，JBoss计划在今年第四季度发布JBoss Messaging，但只要还是捆绑发行，我对其就没什么兴趣。
 
在上次的比较中，OpenJMS已经有比较长的一段时间没有更新了，但最近的四个月似乎又活跃了起来，其预备发行的0.7.7版计划支持JMS 1.1（这个来的太晚了些），其主页上的Changelog表明了接下来的这个版本有着较大的变化。这对那些以前将OpenJMS应用在项目中的人来说是一个不错的消息，但对正在选择JMS的人而言，OpenJMS的这些改进来的还是稍稍晚了些。
 
UberMQ这段时间没有更新，我对它的评价与以前一样，没有任何变化。
 
MantaRay在其主页上更新了一系列的Flash Demos，通过这些Demo，我更坚定了我的看法——MantaRay并不适合用于企业的JMS服务。
 
P2P这个词虽然热，但是不是什么地方都需要P2P的，在我看来JMS就是用于解除各个应用之间的耦合，速度是个关键指标，但比起这个关键指标更重要的是它存在的意义。我更倾向于采用MantaRay在Flash中所反对的那种模型，通过中心服务器进行转发，可以存放离线消息以及解除耦合。更何况，企业应用中很少有类似MantaRay演示DEMO中出现的那种网络拓扑图，并不是任何两个节点之间都是互联互通的。当然，如果MantaRay能够做一些改进，先尝试采用点对点模型，如果点对点失败，这时将消息发送到中心服务器上（但这一切必须对用户透明），我会比较赞成，既具有传统优势，又能提高消息发送接收速度。
 
至于上篇文章中提到的运行其自带的示例出现了问题，这次在Flash演示中终于找到了答案。看来MantaRay真应该提高其示例程序的易用性，这么复杂的操作，要是不看Flash演示，还真难想到该这样操作：（
 
ActiveMQ是让我感到惊讶的一个项目，上次对它的评价似乎有失偏颇。 ActiveMQ支持多种网络拓扑模型，既可以采用传统JMS的Client-Server模型，也可以采用MantaRay的P2P模型，还可以仅仅支持同一JVM内的JMS应用。持久化机制一如既往的优秀，默认采用Apache Derby数据库持久化，也可以配置为各种主流数据库来持久。目前也提供了一简单的JNDI实现，对于JMS应用而言，这已经够用了。
 
但是其缺点也同样明显，本身不提供管理工具；示例代码非常少；虽然主页上的文档看上去比较全面，但是一来缺乏一种有效的组织方式（文档凌乱，用户很难由浅入深进行了解，提高了门槛），二来文档整体的专业性太强（不了解ActiveMQ？看文档去吧，可是文档是写给了解ActiveMQ的用户看的……），对于普通用户而言，门槛有点高。
 
而且感觉ActiveMQ有点不安于JMS的本份，开始做一些周边应用了，看其主页就可以看出来，多了很多比较流行的词汇。说不上这是优点还是缺点，但就我的角度而言，我更希望其专注于做好它的JMS。
 
 JORAM在这段期间推出了4.3.x的版本，也是我们在应用中所采用的版本，我的评价和上次相比没有什么大的变化。主页上说其速度有了提高，但我们应用中JMS数据量相对较少，没有感觉出来。稍微遗憾的是在我们试用的过程中，从4.2.3升级到4.3，老版本的持久化消息都无法在新版本上识别出来，只能全部清空。在兼容性上，看来JORAM还得多下功夫。总而言之，我们在应用中采用JORAM，感觉就是波澜不惊，没碰到什么大问题，也没有什么惊喜。
 
就目前情况，我觉得ActiveMQ和JORAM的竞争力相对较强。再次提醒，JMS的选择一定要慎重，一旦选择好，换起来可是要伤筋动骨的……

1.JMS
   JAVA 消息服务(JMS)定义了Java 中访问消息中间件的接口。JMS 只是接口，并没有给予实现，实现JMS 接口的消息中间件称为JMS Provider，iLink实现了JMS接口，用户可以通过使用JMS接口，在iLink中进行JMS编程。 iLink支持JMS1.0.2版本。

2.JMS接口描述
   JMS 支持两种消息类型PTP 和Pub/Sub，分别称作：PTP Domain 和Pub/Sub Domain，这两种接口都继承统一的JMS父接口，JMS 主要接口如下所示：

MS父接口 PTP Pub/Sub ConnectionFactory QueueConnectionFactory TopicConnectionFactory Connection QueueConnection TopicConnection Destination Queue Topic Session QueueSession TopicSession MessageProducer QueueSender TopicPublisher MessageConsumer QueueReceiver,QueueBrowser TopicSubscriber

                     
   









  

ConnectionFactory ：连接工厂，JMS 用它创建连接
   Connection ：JMS 客户端到JMS Provider 的连接
   Destination ：消息的目的地
   Session： 一个发送或接收消息的线程
   MessageProducer： 由Session 对象创建的用来发送消息的对象
   MessageConsumer： 由Session 对象创建的用来接收消息的对象

3.JMS消息模型
JMS 消息由以下几部分组成：消息头，属性，消息体。
  
3.1 消息头(Header) - 消息头包含消息的识别信息和路由信息，消息头包含一些标准的属性如：JMSDestination,JMSMessageID 等。

消息头  由谁设置 JMSDestination send 或 publish 方法 JMSDeliveryMode send 或 publish 方法 JMSExpiration send 或 publish 方法 JMSPriority send 或 publish 方法 JMSMessageID send 或 publish 方法 JMSTimestamp send 或 publish 方法 JMSCorrelationID 客户 JMSReplyTo 客户 JMSType 客户 JMSRedelivered JMS Provider

       










  
 






3.2 属性(Properties) - 除了消息头中定义好的标准属性外，JMS 提供一种机制增加新属性到消息头中，这种新属性包含以下几种：
   1. 应用需要用到的属性;
   2. 消息头中原有的一些可选属性;
   3. JMS Provider 需要用到的属性。
   标准的JMS 消息头包含以下属性：

JMSDestination 消息发送的目的地 JMSDeliveryMode 传递模式， 有两种模式： PERSISTENT 和NON_PERSISTENT，PERSISTENT 表示该消息一定要被送到目的地，否则会导致应用错误。NON_PERSISTENT 表示偶然丢失该消息是被允许的，这两种模式使开发者可以在消息传递的可靠性和吞吐量之间找到平衡点。 JMSMessageID 唯一识别每个消息的标识，由JMS Provider 产生。 JMSTimestamp 一个消息被提交给JMS Provider 到消息被发出的时间。 JMSCorrelationID 用来连接到另外一个消息，典型的应用是在回复消息中连接到原消息。 JMSReplyTo 提供本消息回复消息的目的地址 JMSRedelivered 如果一个客户端收到一个设置了JMSRedelivered 属性的消息，则表示可能该客户端曾经在早些时候收到过该消息，但并没有签收(acknowledged)。 JMSType 消息类型的识别符。 JMSExpiration 消息过期时间，等于QueueSender 的send 方法中的timeToLive 值或TopicPublisher 的publish 方法中的timeToLive 值加上发送时刻的GMT 时间值。如果timeToLive值等于零，则JMSExpiration 被设为零，表示该消息永不过期。如果发送后，在消息过期时间之后消息还没有被发送到目的地，则该消息被清除。 JMSPriority 消息优先级，从0-9 十个级别，0-4 是普通消息，5-9 是加急消息。JMS 不要求JMS Provider 严格按照这十个优先级发送消息，但必须保证加急消息要先于普通消息到达。

 







3.3 消息体(Body) - JMS API 定义了5种消息体格式，也叫消息类型，你可以使用不同形式发送接收数据并可以兼容现有的消息格式，下面描述这5种类型：

消息类型 消息体 TextMessage java.lang.String对象，如xml文件内容 MapMessage 名/值对的集合，名是String对象，值类型可以是Java任何基本类型 BytesMessage 字节流 StreamMessage Java中的输入输出流 ObjectMessage Java中的可序列化对象 Message 没有消息体，只有消息头和属性

下例演示创建并发送一个TextMessage到一个队列：
TextMessage message = queueSession.createTextMessage();
message.setText(msg_text); // msg_text is a String
queueSender.send(message);

下例演示接收消息并转换为合适的消息类型：
Message m = queueReceiver.receive();
if (m instanceof TextMessage) {
 TextMessage message = (TextMessage) m;
 System.out.println("Reading message: " + message.getText());
} else {
 // Handle error
}

4. 消息的同步异步接收
   消息的同步接收是指客户端主动去接收消息，JMS 客户端可以采用MessageConsumer 的receive方法去接收下一个消息。
   消息的异步接收是指当消息到达时，主动通知客户端。JMS 客户端可以通过注册一个实 现MessageListener 接口的对象到MessageConsumer，这样，每当消息到达时，JMS Provider 会调用MessageListener中的onMessage 方法。


5. PTP模型
PTP(Point-to-Point)模型是基于队列的，发送方发消息到队列，接收方从队列接收消息，队列的存在使得消息的异步传输成为可能。和邮件系统中的邮箱一样，队列可以包含各种消息，JMS Provider 提供工具管理队列的创建、删除。JMS PTP 模型定义了客户端如何向队列发送消息，从队列接收消息，浏览队列中的消息。
   下面描述JMS PTP 模型中的主要概念和对象：

名称 描述 Queue 由JMS Provider 管理，队列由队列名识别，客户端可以通过JNDI 接口用队列名得到一个队列对象。 TemporaryQueue 由QueueConnection 创建，而且只能由创建它的QueueConnection 使用。 QueueConnectionFactory 客户端用QueueConnectionFactory 创建QueueConnection 对象。 QueueConnection 一个到JMS PTP provider 的连接，客户端可以用QueueConnection 创建QueueSession 来发送和接收消息。 QueueSession 提供一些方法创建QueueReceiver 、QueueSender、QueueBrowser 和TemporaryQueue。如果在QueueSession 关闭时，有一些消息已经被收到，但还没有被签收(acknowledged)，那么，当接收者下次连接到相同的队列时，这些消息还会被再次接收。 QueueReceiver 客户端用QueueReceiver 接收队列中的消息，如果用户在QueueReceiver 中设定了消息选择条件，那么不符合条件的消息会留在队列中，不会被接收到。 QueueSender 客户端用QueueSender 发送消息到队列。 QueueBrowser 客户端可以QueueBrowser 浏览队列中的消息，但不会收走消息。 QueueRequestor JMS 提供QueueRequestor 类简化消息的收发过程。QueueRequestor 的构造函数有两个参数：QueueSession 和queue，QueueRequestor 通过创建一个临时队列来完成最终的收发消息请求。 可靠性(Reliability) 队列可以长久地保存消息直到接收者收到消息。接收者不需要因为担心消息会丢失而时刻和队列保持激活的连接状态，充分体现了异步传输模式的优势。

        
      
  
 

6. PUB/SUB模型
JMS Pub/Sub 模型定义了如何向一个内容节点发布和订阅消息，这些节点被称作主题(topic)。
   主题可以被认为是消息的传输中介，发布者(publisher)发布消息到主题，订阅者(subscribe) 从主题订阅消息。主题使得消息订阅者和消息发布者保持互相独立，不需要接触即可保证消息的传送。
   下面描述JMS Pub/Sub 模型中的主要概念和对象：

名称 描述 订阅(subscription) 消息订阅分为非持久订阅(non-durable subscription)和持久订阅(durable subscrip-tion)，非持久订阅只有当客户端处于激活状态，也就是和JMS Provider 保持连接状态才能收到发送到某个主题的消息，而当客户端处于离线状态，这个时间段发到主题的消息将会丢失，永远不会收到。持久订阅时，客户端向JMS 注册一个识别自己身份的ID，当这个客户端处于离线时，JMS Provider 会为这个ID 保存所有发送到主题的消息，当客户再次连接到JMS Provider时，会根据自己的ID 得到所有当自己处于离线时发送到主题的消息。 Topic 主题由JMS Provider 管理，主题由主题名识别，客户端可以通过JNDI 接口用主题名得到一个主题对象。JMS 没有给出主题的组织和层次结构的定义，由JMS Provider 自己定义。 TemporaryTopic 临时主题由TopicConnection 创建，而且只能由创建它的TopicConnection 使用。临时主题不能提供持久订阅功能。 TopicConnectionFactory 客户端用TopicConnectionFactory 创建TopicConnection 对象。 TopicConnection TopicConnection 是一个到JMS Pub/Sub provider 的连接，客户端可以用TopicConnection创建TopicSession 来发布和订阅消息。 TopicSession TopicSession 提供一些方法创建TopicPublisher、TopicSubscriber、TemporaryTopic 。它还提供unsubscribe 方法取消消息的持久订阅。 TopicPublisher 客户端用TopicPublisher 发布消息到主题。 TopicSubscriber 客户端用TopicSubscriber 接收发布到主题上的消息。可以在TopicSubscriber 中设置消息过滤功能，这样，不符合要求的消息不会被接收。 Durable TopicSubscriber 如果一个客户端需要持久订阅消息，可以使用Durable TopicSubscriber，TopSession 提供一个方法createDurableSubscriber创建Durable TopicSubscriber 对象。 恢复和重新派送(Recovery and Redelivery) 非持久订阅状态下，不能恢复或重新派送一个未签收的消息。只有持久订阅才能恢复或重新派送一个未签收的消息。 TopicRequestor JMS 提供TopicRequestor 类简化消息的收发过程。TopicRequestor 的构造函数有两个参数：TopicSession 和topic。TopicRequestor 通过创建一个临时主题来完成最终的发布和接收消息请求。 可靠性(Reliability) 当所有的消息必须被接收，则用持久订阅模式。当丢失消息能够被容忍，则用非持久订阅模式。

  
  
  
  
  
  
  
  
    













7. 开发JMS的步骤
   广义上说，一个JMS 应用是几个JMS 客户端交换消息，开发JMS 客户端应用由以下几步构成：
用JNDI 得到ConnectionFactory 对象；
用JNDI 得到目标队列或主题对象，即Destination 对象；
用ConnectionFactory 创建Connection 对象；
用Connection 对象创建一个或多个JMS Session；
用Session 和Destination 创建MessageProducer 和MessageConsumer；
通知Connection 开始传递消息。

现在我可以使用 JNDI 吗？

是的，Sun Microsystems 已经将 JNDI 作为一个 Java Standard Extension 发布了。Sun Microsystems 还为很多命名服务和目录服务（如 LDAP, NIS, CORBA (COS) Naming 和文件）发布了无缝地插入在 JNDI 后面的服务提供程序。这些服务提供程序以及其他供应商提供的服务提供程序都可从 下载 处得到。

JNDI 用于 Java 平台中的什么地方？

HotJava Views 1.1 使用 JNDI 来访问 LDAP。像 Enterprise JavaBeans, Java Message Service, JDBC 2.0 这样的 Enterprise API 将 JNDI 用于命名和目录用途。RMI over IIOP 应用程序可以使用 JNDI 来访问 CORBA (COS) 命名服务。

谁将提供 JNDI 的实现？

在写这篇文章时，IBM, Novell, Sun 和 WebLogic 已经为 JNDI 提供了服务提供程序。我们维护有一个公共可用的服务提供程序的 列表 。

JNDI 为哪些协议提供了接口？

JNDI 本身独立于任何特定目录访问协议。单独的服务提供程序决定所支持的协议。将会有不同供应商提供的流行协议（比如 LDAP, NDS, DNS 和 NIS(YP)）的提供程序实现。

JNDI 与 LDAP 的关系如何？

JNDI 提供目录和命名的一个优良的面向对象的抽象。开发人员使用 JNDI 可以开发出使用 LDAP 或其他访问协议的查询来检索结果；但是他们并不局限于 LDAP，也不是必须开发与 LDAP 相关的应用程序。JNDI 支持 LDAP v3 中的关键功能。

JNDI 与 Netscape 的 Java LDAP API 的关系如何？

Netscape 的 API 是特定于 LDAP 的。它用于对 LDAP 目录的低级别访问。它暴露应用程序一般不需要知道的协议细节。
JNDI 是 Java 程序的一个普通目录 API。它类似用于访问文件的 java.io.File 类。可能会有一些需要在协议级别处理文件的管理程序（比如 NFS），但是所有的 Java 应用程序一般都使用 File 类来访问文件系统。类似地，大多数 Java 程序应该使用 JNDI 来访问目录。需要在协议级别处理目录内容的应用程序可能会选择使用 Netscape 的 API。

JNDI 与用于命名的 OMG 的 CORBA 标准的关系如何？

Java CORBA 应用程序可以使用 JNDI 来访问 CORBA (COS) 名称服务，以及其他命名服务和目录服务。它为应用程序提供一个接口，用于访问所有这些命名服务和目录服务。

通过使用 JNDI，Java CORBA 应用程序还可以使用像 LDAP 这样的分布式企业级服务来存储对象引用。

JNDI 与 Microsoft 的 ADSI 的关系如何？

Java ADSI 包允许 Java 程序基于 COM 模型访问 Active Directory。尽管它可用于访问其他目录，但是它是一个以 Windows 为中心的解决方案。

JNDI 提供 Java 应用程序使用 Java 对象模型来访问目录，而不管这些应用程序是运行在 Windows 上，还是在访问 Active Directory。例如，您可以处理像 AWT 和 JavaBeans 组件这样的对象，将它们绑定到目录中，然后再返回来查找它们，而不用做任何转换或者处理数据表示问题。

什么是 XFN，它与 JNDI 的关系如何？

XFN 就是 X/Open Federated Naming，即一个基于 C 的标准，用于访问多个有可能联盟的命名服务和目录服务。熟悉 XFN 的程序员会发现使用 JNDI 很容易。

安全性如何？

不同目录对待安全性的方式不同。JNDI 允许应用程序与特定于目录的安全系统协同工作。在未来，基于 JNDI 的应用程序将能够为 Java 平台开发的任何单点登录机制的优势。

     通常我们在程序中new出Context（在目录结构中的每一个结点称为context。每一个JNDI名字都是相对于context的）需要提前做些工作（如果是在j2ee容器中的代码则不必），需要两步，一是实现类的initcontextfactory,另一个就是provider_url,  它我感觉相当于给出具体资源在什么位置，并且以什么协议的形式作为其目录方案。有了这两个我们就能new出context,然后lookup出资源。以文件系统为命名服务的更简单，它只须一个factory就可以了。