我们在测试某类时，由于它要与其他类发生联系，因此往往在测试此类的代码中也将与之联系的类也一起测试了。这种测试，将使被测试的类直接依赖于其他 类，一旦其他类发生改变，被测试类也随之被迫改变。更重要的是，这些其他类可能尚未经过测试，因此必须先测试这些类，才能测试被测试类。这种情况下，测试 驱动开发成为空谈。而如果其他类中也引用了被测试类，我们到底先测试哪一个类？因此，在测试中，如果我们能将被测试类孤立起来，使其完全不依赖于其他类的 具体实现，这样，我们就能做到测试先行，先测试哪个类，就先实现哪个类，而不管与之联系的类是否已经实现。

虚拟对象(mock object)就是为此需要而诞生的。它通过JDK中的反射机制，在运行时动态地创建虚拟对象。在测试代码中，我们可以验证这些虚拟对象是否被正确地调用 了，也可以在明确的情况下，让其返回特定的假想值。而一旦有了这些虚拟对象提供的服务，被测试类就可以将虚拟对象作为其他与之联系的真实对象的替身，从而 轻松地搭建起一个很完美的测试环境。

JMock是帮助创建mock对象的工具，它基于Java开发，在Java测试与开发环境中有不可比拟的优势，更重要的是，它大大简化了虚拟对象的使用。

本文中，通过一个简单的测试用例来说明JMock如何帮助我们实现这种孤立测试。有三个主要的类，User，UserDAO，及 UserService。本文中，我们只需测试UserService，准备虚拟UserDAO。对于User，由于本身仅是一个过于简单的POJO，可 以不用测试。但如果你是一个完美主义者，也可以使用JMock的虚拟它。在这领域，JMock几乎无所不能。:)

User是一个POJO，用以在视图中传输数据及映射数据库。其代码如下：

package com.sarkuya.model;

public class User {
    private String name;

    public User() {
    }
   
    public User(String name) {
        this.name = name;
    }
   
    public String getName() {
        return name;
    }
   
    public void setName(String name) {
        this.name = name;
    }
}

UserDAO负责与数据库打交道，通过数据库保存、获取User的信息。尽管我们可以不用知道JMock如何通过JDK的反射机制来实现孤立测试，但至 少应知道，JDK的反射机制要求这些在运行时创建的动态类必须定义接口。在使用JMock的环境中，由于我们要虚拟UserDAO，意味着UserDAO 必须定义接口。代码如下：

package com.sarkuya.dao;

import com.sarkuya.model.User;

public interface UserDAO {
    public void saveUser(User user);
    public User getUser(Long id);
}

UserService存有UserDAO的引用，通过其对外提供应用级的服务。相应地，我们先定义了其接口(尽管在本文中，作为被测试类，UserService不需要有接口，但如果以后此类需要被虚拟，也应该带有接口，基于此原因，我们也为其定义了接口)。

package com.sarkuya.service;

import com.sarkuya.dao.UserDAO;
import com.sarkuya.model.User;

public interface UserService {
    public void setUserDAO(UserDAO userDAO);
   
    public void saveUser(User user);
    public User getUser(Long id);
}

可以看到，除了setUserDAO()外，其另外的方法与UserDAO一样。这是设计模式中门面模式的典型应用，应用只通过UserService提供服务，而UserService在内部通过调用UserDAO来实现相应的功能。

根据测试先行的原则，你应该先写测试，再编写实现。这里先编写实现的原因，主要是使读者更加清楚我们接着要测试什么。由于本文是着重介绍JMock的使用，加上UserServiceImpl比较简单，因此先列出其代码如下：

package com.sarkuya.service.impl;

import com.sarkuya.dao.UserDAO;
import com.sarkuya.model.User;
import com.sarkuya.service.UserService;

public class UserServiceImpl implements UserService {
    private UserDAO userDAO;
   
    public UserServiceImpl() {
    }

    public void setUserDAO(UserDAO userDAO) {
        this.userDAO = userDAO;
    }

    public User getUser(Long id) {
        return userDAO.getUser(id);
    }

    public void saveUser(User user) {
        userDAO.saveUser(user);
    }
}

下面是UserService的测试代码：

package com.sarkuya.service;

import com.sarkuya.dao.UserDAO;
import com.sarkuya.model.User;
import com.sarkuya.service.impl.UserServiceImpl;
import junit.framework.*;
import org.jmock.Mock;
import org.jmock.MockObjectTestCase;

public class UserServiceTest extends MockObjectTestCase {
    private UserService userService = new UserServiceImpl();
   
    private Mock userDAO = null;
   
    public UserServiceTest(String testName) {
        super(testName);
    }
   
    protected void setUp() throws Exception {
        userDAO = new Mock(UserDAO.class);
        userService.setUserDAO((UserDAO)userDAO.proxy());
    }
   
    protected void tearDown() throws Exception {
    }
   
    public static Test suite() {
        TestSuite suite = new TestSuite(UserServiceTest.class);
       
        return suite;
    }
   
    public void testGetUser() {
        User fakeUser = new User("John");
        userDAO.expects(once()).method("getUser").with(eq(1L)).will(returnValue(fakeUser));
       
        User user = userService.getUser(1L);
        assertNotNull(user);
        assertEquals("John", user.getName());
    }
   
    public void testSaveUser() {
        User fakeUser = new User("John");
       
        userDAO.expects(once()).method("getUser").with(eq(1L)).will(returnValue(fakeUser));
        User user = userService.getUser(1L);
        assertEquals("John", user.getName());
       
        userDAO.expects(once()).method("saveUser").with(same(fakeUser));
        user.setName("Mike");
        userService.saveUser(user);
       
        userDAO.expects(once()).method("getUser").with(eq(1L)).will(returnValue(user));
        User modifiedUser = userService.getUser(1L);
        assertEquals("Mike", user.getName());
    }
}

此段代码有几点应注意：

1、此测试类继承了JMock的MockObjectTestCase

2、private Mock userDAO = null;说明userDao是一个准备虚拟的对象

3、在setup()中，将userDAO.class传入Mock()后，再通过proxy()方法返回一个UserDAO的代理类实例(即虚拟对象实例)，并赋值于userService

4、在testGetUser()方法中，如果我们先将第一行及第二行代码屏蔽掉，可以看出，这是一个真实环境下的测试代码。先获取一个User， 然后确认其非空值，再确认其姓名为“John”。此时，在真实环境下，这段代码要测试成功的前提必须是UserDAO已经连接到了数据库，然后返回一个 User后传给UserService。
但问题是，到目前为止，且不说UserDAO还未经历连接数据库这一系列繁琐而痛苦的过程，我们甚至还未实现UserDAO的接口！那么，为何加上第一行 及第二行代码后就可以了呢？这正是JMock的威力所在。先实例化一个测试用的fakeUser，然后通过一系列的指令，在第二行代码中告诉JMock应 该如何“做假”。尽管这句代码很长，我们可作如下理解：
1) userDAO.expects(once())：我们期望userDAO的某方法被执行一次，如果此方法未被执行，或者执行了二次以上，测试就不会通过
2) method("getUser")：这个期望被执行一次的方法名为userDAO.getUser()
3) with(eq(1L))：执行getUser()方法时，确认其传入的参数值为“1L”
4) will(returnValue(fakeUser))：上述条件均满足后，返回一个虚假的对象，即我们前面实例化的fakeUser
总体来说，当设定好第二行语句后，JMock就在后台监控着，确保userDAO.getUser()必须，且只被执行一次，且参数“1L”已经正确地传给了此方法，一旦这些条件被满足，就返回fakeUser。
而在第三行，User user = userService.getUser(1L)将触发所有这些条件，作为奖励，它接受了奖品fakeUser并赋值于user对象。而下面第四行及第五行均对此user对象进行测试，不通过才怪。

5) testSaveUser()方法中的原理类似。其思路是，将id为“1”的user从数据库中取出，将其名改为“Mike”，再存回数据库，然后再从数据库中取出此user，确保其名字已被改变。
第五行userDAO.expects(once()).method("saveUser").with(same(fakeUser))比较特殊。首 先，with(same(fakeUser))说明，传入参数必须是fakeUser此实例，尽管我们在下面的语句中通过user.setName ("Mike")，但只是改变了其name的属性，而fakeUser的实例引用并未发生改变，因此可以满足条件。其次，其后没有.will (returnValue(fakeUser))，因为userDAO.saveUser()不需要返回任何对象或基本数据类型。
另外，当再次执行userDAO.expects()时，JMock将重设其监控条件。我们也可以通过userDAO.reset()来显式是清除监控条件。

通过以上实例代码及其说明，我们看出，用好JMock的关键是先设置监控条件，再写相应的测试语句。一旦设好监控条件后，在某段代码块执行完毕时， 如果监控条件未得到满足，或是没有通过expects()再次重设条件，或通过reset()来显式是清除监控条件，测试将无法通过。

以上介绍了JMock的基本使用方法。而这种基本用法，占了全面掌握JMock所需学习的知识70%以上。关于JMock的更多细节，感兴趣的读者可以访问JMock的网站进一步学习。

response.setHeader("Content-Disposition", "inline; filename="fliename)
点击打开会在ie中打开。

需要说明的有三点：
Ø 中文文件名需要进行iso8859-1转码方可正确显示：
fileName = new String(fileName.getBytes("GBK"),"iso8859-1");
Ø 传递的文件名，需要包含后缀名（如果此文件有后缀名），否则丢失文件的属性，而不能自行选择相关程序打开。
Ø 有下载前询问（是打开文件还是保存到计算机）和通过IE浏览器直接选择相关应用程序插件打开两种方式，前者如上代码所示，后者如下：
response.setHeader("Content-disposition","filename="+ "Example.xls" );
3. 在研究文件的上传及下载过程中，有几点体会
程序的I/O操作往往是性能的瓶颈所在，java io定义了两个基本的抽象类:InputStream和OutputStream,对于不同的数据类型比如磁盘，网络又提供了不同的实现，java.io 也提供了一些缓冲流(BufferedStream)，使硬盘可以很快的读写一大块的数据, 而Java基本的I/O类一次只能读写一个字节,但缓冲流(BufferedStream)可以一次读写一批数据，,缓冲流(Buffered Stream)大大提高了I/O的性能。所以:
Ø小块小块的读写数据会非常慢,因此,尽量大块的读写数据
Ø使用BufferedInputStream和BufferedOutputStream来批处理数据以提高性能
Ø对象的序列化(serialization)非常影响I/O的性能,尽量少用

注：
1、Servlet中输出流的简单处理方法：      

      //得到当前web应用根目录下test.txt文件的实际物理路径.
       String path = getServletContext().getRealPath("/test.txt");    

       OutputStream os = response.getOutputStream();
       InputStream is = new FileInputStream(path);
       byte[] buff = new byte[1024];
       int len;
   while((len = is.read(buff)) !=  -1) {
            os.write(buff, 0, len);
       }
       
       is.close();
       os.close(); 

2、输出流跟PrintWriter out = response.getWriter();不能同时使用。

Main Attributes

• general main attributes

• Manifest-Version:
Defines the manifest file version. The value is a legitimate version number, as described in the above spec.
 
• Created-By:

Defines the version and the vendor of the java implementation on top of which this manifest file is generated. This attribute is generated by the jar tool.
 
• Signature-Version:

Defines the signature version of the jar file. The value should be a valid version-number string.
 
• Class-Path :

The value of this attribute specifies the relative URLs of the extensions or libraries that this application or extension needs. URLs are separated by one or more spaces. The application or extension class loader uses the value of this attribute to construct its internal search path.
 
• attribute defined for stand-alone applications
This attribute is used by stand-alone applications that are bundled into executable jar files which can be invoked by the java runtime directly by running "java -jar x.jar".
• Main-Class :

The value of this attribute defines the relative path of the main application class which the launcher will load at startup time. The value must not have the .class extension appended to the class name.

• attributes defined for applets
These attributes is used by an applet which is bundled into JAR files to define requirements, version and location information for the extensions which this applet depends on. (see  Extension Versioning ). 
• Extension-List:

This attribute indicates the extensions that are needed by the applet. Each extension listed in this attribute will have a set of additional attributes that the applet uses to specify which version and vendor of the extension it requires.
 
• <extension>-Extension-Name :

This attribute is the unique name of the extension. The Java Plug-in will compare the value of this attribute with the Extension-Name attribute in the manifests of installed extensions to determine if the extension is installed.
 
• <extension>-Specification-Version

This attribute specifies the minimum extension specification version that is required by the applet. The Java Plug-in will compare the value of this attribute with the Specification-Version attribute of the installed extension to determine if the extension is up to date.
 
• <extension>-Implementation-Version

This attritute specifies the minimum extension implementation version number that is required by the applet. The Java Plug-in will compare the value of this attribute with the Implementation-Version attribute of the installed extension to see if a more recent implementation needs to be downloaded.
 
• <extension>-Implementation-Vendor-Id

This attribute can be used to identify the vendor of an extension implementation if the applet requires an implementation from a specific vendor. The Java Plug-in will compare the value of this attribute with the Implementation-Vendor-Id attribute of the installed extension.
 
• <extension>-Implementation-URL

This attribute specifies a URL that can be used to obtain the most recent version of the extension if the required version is not already installed.
 
• attribute defined for extension identification
This attribute is used by extensions to define their unique identity.
• Extension-Name:
This attribute specifies a name for the extension contained in the Jar file. The name should be a unique identifier such as the name of the main package comprising the extension.
 
• attributes defined for extension and  package versioning  and sealing information
These attributes define features of the extension which the JAR file is a part of. The value of these attributes apply to all the packages in the JAR file, but can be overridden by per-entry attributes. 
• Implementation-Title :
The value is a string that defines the title of the extension implementation. 
• Implementation-Version :

The value is a string that defines the version of the extension implementation.
 
• Implementation-Vendor :

The value is a string that defines the organization that maintains the extension implementation.
 
• Implementation-Vendor-Id :

The value is a string id that uniquely defines the organization that maintains the  extension implementation.
 
• Implementation-URL :

This attribute defines the URL from which the extension implementation can be downloaded from.
 
•  Specification-Title :

The value is a string that defines the title of the extension specification.
 
• Specification-Version :

The value is a string that defines the version of the extension specification.
 
• Specification-Vendor :

The value is a string that defines the organization that maintains the extension specification.

• Sealed :

This attribute defines whether this JAR file is sealed or not. The value can be either "true" or "false", case is ignored. If it is set to "true", then all the packages in the JAR file are defaulted to be sealed, unless they are defined otherwise individually.

ClassNotFoundException

ClassNotFoundException 是最常见的类装入异常类型。它发生在装入阶段。Java 规范对 ClassNotFoundException 的描述是这样的：

当应用程序试图通过类的字符串名称，使用以下三种方法装入类，但却找不到指定名称的类定义时抛出该异常。

• 类 Class 中的 forName() 方法。
• 类 ClassLoader 中的 findSystemClass() 方法。
• 类 ClassLoader 中的 loadClass() 方法。

所以，如果显式地装入类的尝试失败，那么就抛出 ClassNotFoundException。清单 1 中的测试用例提供的示例代码抛出了一个 ClassNotFoundException：

												
														

														
import java.net.MalformedURLException;
import java.net.URL;
import java.net.URLClassLoader;

public class ClassNotFoundExceptionTest {

    public static void main(String args[]) {
        try {
            URLClassLoader loader = new URLClassLoader(new URL[] { new URL(
                "file://C:/CL_Article/ClassNotFoundException/")});
            loader.loadClass("DoesNotExist");
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        } catch (MalformedURLException e) {
            e.printStackTrace();
        }
    }
}
										

这个测试用例定义了一个类装入器（MyClassLoader），用于装入一个不存在的类（DoesNotExist）。当它运行时，会出现以下异常：

												
														
java.lang.ClassNotFoundException: DoesNotExist
    at java.net.URLClassLoader.findClass(URLClassLoader.java:376)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:572)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:504)
    at ClassNotFoundExceptionTest.main(ClassNotFoundExceptionTest.java:11)
										

因为这个测试试图使用对 loadClass() 的显式调用来进行装入，所以抛出 ClassNotFoundException。

通过抛出 ClassNotFoundException，类装入器提示，定义类时所需要的字节码在类装入器所查找的位置上不存在。这些异常修复起来通常比较简单。可以用 IBM 的 verbose 选项检查类路径，确保使用的类路径设置正确（要获得 verbose 的更多信息，请参阅本系列的 第一篇文章）。如果类路径设置正确，但是仍然看到这个错误，那么就是需要的类在类路径中不存在。要修复这个问题，可以把类移动到类路径中指定的目录或 JAR 文件中，或者把类所在的位置添加到类路径中。

NoClassDefFoundError

NoClassDefFoundError 是类装入器在装入阶段抛出的另一个常见异常。JVM 规范对 NoClassDefFoundError 的定义如下：

如果 Java 虚拟机或 ClassLoader 实例试图装入类定义（作为正常的方法调用的一部分，或者作为使用 new 表达式创建新实例的一部分），但却没有找到类定义时抛出该异常。

当目前执行的类已经编译，但是找不到它的定义时，会存在 searched-for 类定义。

实际上，这意味着 NoClassDefFoundError 的抛出，是不成功的隐式类装入的结果。

清单 2 到清单 4 的测试用例产生了 NoClassDefFoundError，因为类 B 的隐式装入会失败：

												
														

														
public class NoClassDefFoundErrorTest {
	public static void main(String[] args) {
		A a = new A();
	}
}
										

												
														

														
public class A extends B {
}
										

												
														

														
public class B {
}
										

这几个清单中的代码编译好之后，删除 B 的类文件。当代码执行时，就会出现以下错误：

												
														
Exception in thread "main" java.lang.NoClassDefFoundError: B
    at java.lang.ClassLoader.defineClass0(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:810)
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:147)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:475)
    at java.net.URLClassLoader.access$500(URLClassLoader.java:109)
    at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:848)
    at java.security.AccessController.doPrivileged1(Native Method)
    at java.security.AccessController.doPrivileged(AccessController.java:389)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:371)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:572)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:442)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:504)
    at NoClassDefFoundErrorTest.main(NoClassDefFoundErrorTest.java:3)

										

类 A 扩展了类 B；所以，当类 A 装入时，类装入器会隐式地装入类 B。因为类 B 不存在，所以抛出 NoClassDefFoundError。如果显式地告诉类装入器装入类 B（例如通过 loadClass("B") 调用），那么就会抛出 ClassNotFoundException。

显然，要修复这个特殊示例中的问题，在对应的类装入器的类路径中，必须存在类 B。这个示例看起来可能价值不大、也不真实，但是，在复杂的有许多类的真实系统中，会因为类在打包或部署期间的遗失而发生这类情况。

在这个例子中，A 扩展了 B；但是，即使 A 用其他方式引用 B，也会出现同样的问题 —— 例如，以方法参数引用或作为实例字段。如果两个类之间的关系是引用关系而不是继承关系，那么会在第一次使用 A 时抛出错误，而不是在装入 A 时抛出。

ClassCastException

类装入器能够抛出的另一个异常是 ClassCastException。它是在类型比较中发现不兼容类型的时候抛出的。JVM 规范指定 ClassCastException 是：

该异常的抛出，表明代码企图把对象的类型转换成一个子类，而该对象并不是这个子类的实例。

清单 5 演示的代码示例会产生一个 ClassCastException：

												
														

														
public class ClassCastExceptionTest {
    public ClassCastExceptionTest() {
    }

    private static void storeItem(Integer[] a, int i, Object item) {
        a[i] = (Integer) item;
    }

    public static void main(String args[]) {
        Integer[] a = new Integer[3];
        try {
            storeItem(a, 2, new String("abc"));
        } catch (ClassCastException e) { 
            e.printStackTrace();
        }
    }
}
										

在清单 5 中，调用了 storeItem() 方法，使用一个 Integer 数组、一个 int 和一个字符串作为参数。但是在内部，该方法做了两件事：

• 隐式地把 String 对象类型转换成 Object 类型（用于参数列表）。
• 显式地把这个 Object 类型转换成 Integer 类型（在方法定义中）。

当程序运行时，会出现以下异常：

												
														
java.lang.ClassCastException: java.lang.String
    at ClassCastExceptionTest.storeItem(ClassCastExceptionTest.java:6)
    at ClassCastExceptionTest.main(ClassCastExceptionTest.java:12)
										

这个异常是由显式类型转换抛出的，因为测试用例试图把类型为 String 的东西转换成 Integer。

当检查对象（例如清单 5 中的 item）并把类型转换成目标类（Integer）时，类装入器会检查以下规则：

• 对于普通对象（非数组）：对象必须是目标类的实例或目标类的子类的实例。如果目标类是接口，那么会把它当作实现了该接口的一个子类。
  
  
• 对于数组类型：目标类必须是数组类型或 java.lang.Object、java.lang.Cloneable 或 java.io.Serializable。

如果违反了以上任何一条规则，那么类装入器就会抛出 ClassCastException。修复这类异常的最简单方式就是仔细检查对象要转换到的类型是否符合以上提到的规则。在某些情况下，在做类型转换之前用 instanceof 进行检查是有意义的。

UnsatisfiedLinkError

在把本机调用链接到对应的本机定义时，类装入器扮演着重要角色。如果程序试图装入一个不存在或者放错的本机库时，在链接阶段的解析过程会发生 UnsatisfiedLinkError。JVM 规范指定 UnsatisfiedLinkError 是：

对于声明为 native 的方法，如果 Java 虚拟机找不到和它对应的本机语言定义，就会抛出该异常。

当调用本机方法时，类装入器会尝试装入定义了该方法的本机库。如果找不到这个库，就会抛出这个错误。

清单 6 演示了抛出 UnsatisfiedLinkError 的测试用例 ：

												
														

														
public class UnsatisfiedLinkErrorTest {

    public native void call_A_Native_Method();

    static {
        System.loadLibrary("myNativeLibrary");
    }

    public static void main(String[] args) {
        new UnsatisfiedLinkErrorTest().call_A_Native_Method();
    }
}
										

这段代码调用本机方法 call_A_Native_Method()，该方法是在本机库 myNativeLibrary 中定义的。因为这个库不存在，所以在程序运行时会发生以下错误：

												
														
The java class could not be loaded. java.lang.UnsatisfiedLinkError:
  Can't find library myNativeLibrary  (myNativeLibrary.dll)
  in sun.boot.library.path or java.library.path
sun.boot.library.path=D:\sdk\jre\bin
java.library.path= D:\sdk\jre\bin

at java.lang.ClassLoader$NativeLibrary.load(Native Method)
    at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2147)
    at java.lang.ClassLoader.loadLibrary(ClassLoader.java:2006)
    at java.lang.Runtime.loadLibrary0(Runtime.java:824)
    at java.lang.System.loadLibrary(System.java:908)
    at UnsatisfiedLinkErrorTest.<clinit>(UnsatisfiedLinkErrorTest.java:6)

										

本机库的装入由调用 System.loadLibrary() 方法的类的类装入器启动 —— 在清单 6 中，就是 UnsatisfiedLinkErrorTest 的类装入器。根据使用的类装入器，会搜索不同的位置：

• 对于由 bootstrap 类装入器装入的类，搜索 sun.boot.library.path。
• 对于由扩展类装入器装入的类，先搜索 java.ext.dirs，然后是 sun.boot.library.path，然后是 java.library.path。
• 对于由系统类装入器装入的类，搜索 sun.boot.library.path，然后是 java.library.path。

在清单 6 中，UnsatisfiedLinkErrorTest 类是由系统类装入器装入的。要装入所引用的本机库，这个类装入器先查找 sun.boot.library.path，然后查找 java.library.path。因为在两个位置中都没有需要的库，所以类装入器抛出 UnsatisfiedLinkageError。

一旦理解了库装入过程所涉及的类装入器，就可以通过把库放在合适位置来解决这类问题。

ClassCircularityError

JVM 规范指定 ClassCircularityError 的抛出条件是：

类或接口由于是自己的超类或超接口而不能被装入。

这个错误是在链接阶段的解析过程中抛出的。这个错误有点奇怪，因为 Java 编译器不允许发生这种循环情况。但是，如果独立地编译类，然后再把它们放在一起，就可能发生这个错误。请设想以下场景。首先，编译清单 7 和清单 8 中的类：

												
														

														
public class A extends B {
}
										

												
														

														
public class B {
}
										

然后，分别编译清单 9 和清单 10 中的类：

												
														

														
public class A {
}
										

												
														

														
public class B extends A {
}
										

最后，采用清单 7 的类 A 和清单 10 的类 B，并运行一个应用程序，试图装入 A 或者 B。这个情况看起来可能不太可能，但是在复杂的系统中，在把不同部分放在一起的时候，可能会发生类似的情况。

显然，要修复这个问题，必须避免循环的类层次结构。

ClassFormatError

JVM 规范指出，抛出 ClassFormatError 的条件是：

负责指定所请求的编译类或接口的二进制数据形式有误。

这个异常是在类装入的链接阶段的校验过程中抛出。如果字节码发生了更改，例如主版本号或次版本号发生了更改，那么二进制数据的形式就会有误。例如，如果对字节码故意做了更改，或者在通过网络传送类文件时现出了错误，那么就可能发生这个异常。

修复这个问题的惟一方法就是获得字节码的正确副本，可能需要重新进行编译。

ExceptionInInitializerError

根据 JVM 规范，抛出 ExceptionInInitializer 的情况是：

• 如果初始化器突然完成，抛出一些异常 E，而且 E 的类不是 Error 或者它的某个子类，那么就会创建 ExceptionInInitializerError 类的一个新实例，并用 E 作为参数，用这个实例代替 E。
  
  
• 如果 Java 虚拟机试图创建类 ExceptionInInitializerError 的新实例，但是因为出现 Out-Of-Memory-Error 而无法创建新实例，那么就抛出 OutOfMemoryError 对象作为代替。

清单 8 中的代码抛出 ExceptionInInitializerError：

												
														

														
public class ExceptionInInitializerErrorTest {
    public static void main(String[] args) {
        A a = new A();
    }
}

class A {
    // If the SecurityManager is not turned on, a 
    // java.lang.ExceptionInInitializerError will be thrown 
    static {
        if(System.getSecurityManager() == null)
            throw new SecurityException();
    }
}
										

当静态代码块中发生异常时，会被自动捕捉并用 ExceptionInInitializerError 包装该异常。在下面的输出中可以看到这点：

												
														
Exception in thread "main" java.lang.ExceptionInInitializerError
   at ExceptionInInitializerErrorTest.main(ExceptionInInitializerErrorTest.java:3)
Caused by: java.lang.SecurityException
   at A.<clinit>(ExceptionInInitializerErrorTest.java:12)
   ... 1 more
										

这个错误在类装入的初始化阶段抛出。修复这个错误的方法是检查造成 ExceptionInInitializerError 的异常（在堆栈跟踪的 Caused by: 下显示）并寻找阻止抛出这个异常的方式。

GWT lets you avoid many of these headaches while offering your users the same dynamic, standards-compliant experience. You write your front end in the Java programming language, and the GWT compiler converts your Java classes to browser-compliant JavaScript and HTML.

GWT website: http://code.google.com/webtoolkit/