Welcome to Java Tech. This new column explores all kinds of Java technology in terms of theory and practicality. For example, one article might investigate Tiger's generics language feature, whereas another article might apply Java to the construction of a web shopping cart application or a "smart" computer game that can beat the pants off many game players. I hope you enjoy the adventure.

Speaking of Tiger (also known as J2SE 5.0), this article focuses on the new variable arguments language feature. After examining basic syntax, we'll cover diverse uses for variable arguments.

Note: This column is based on J2SE 5. Sun has established an external version number of 5.0 and an internal version number of 1.5.0 to this release of the Java 2 platform.

Basic Syntax and Uses

Tiger's variable arguments language feature makes it possible to call a method with a variable number of arguments. Before making that call, the rightmost parameter in the method's parameter list must conform to the following syntax:

type ... variableName

The ellipsis (...) identifies a variable number of arguments, and is demonstrated in the following summation method.

static int sum (int  numbers)
{
   int total = 0;
   for (int i = 0; i < numbers.length; i++)
        total += numbers [i];
   return total;
}

Call the summation method with as many comma-delimited integer arguments as you desire -- within the JVM's limits. Some examples: sum (10, 20) and sum (18, 20, 305, 4).

Look closely at the method declaration above, and you'll discover that variable arguments is implemented in terms of arrays. (numbers.length and numbers [i] are the giveaways.) It turns out that the ellipsis is just syntactic sugar for having the compiler create and initialize an array of same-typed values and pass that array's reference to a method. For example, the compiler converts the method call sum (10, 20) into an equivalent sum (new int [] {10, 20}) method call.

Can you change int ... numbers to int [] numbers and still invoke sum (10, 20)? Answer: no. If you try to do that, the compiler reports an error. Use sum (new int [] {10, 20}) instead.

Summing a list of integers is one basic use for variable arguments. Computing the average of a list of floating-point numbers, concatenating a list of strings into a single string, and finding the maximum/minimum values in lists of floating-point numbers are other basic uses. The following BasicUses.java source code demonstrates these basic uses, to give you more exposure to variable arguments.

BasicUses.java
// BasicUses.java
class BasicUses
{
   public static void main (String [] args)
   {
      System.out.println ("Average: " +
                          avg (20.3, 3.1415, 32.3));
      System.out.println ("Concatenation: " +
                          concat ("Hello", " ", "World"));
      System.out.println ("Maximum: " +
                          max (30, 22.3, -9.3, 173.2));
      System.out.println ("Minimum: " +
                          min (30, 22.3, -9.3, 173.2));
      System.out.println ("Sum: " +
                          sum (20, 30));
   }
   static double avg (double  numbers)
   {
      double total = 0;
      for (int i = 0; i < numbers.length; i++)
           total += numbers [i];
      return total / numbers.length;
   }
   static String concat (String  strings)
   {
      StringBuilder sb = new StringBuilder ();
      for (int i = 0; i < strings.length; i++)
           sb.append (strings [i]);
      return sb.toString ();
   }
   static double max (double  numbers)
   {
      double maximum = Double.MIN_VALUE;
      for (int i = 0; i < numbers.length; i++)
           if (numbers [i] > maximum)
               maximum = numbers [i];
      return maximum;
   }
   static double min (double  numbers)
   {
      double minimum = Double.MAX_VALUE;
      for (int i = 0; i < numbers.length; i++)
           if (numbers [i] < minimum)
               minimum = numbers [i];
      return minimum;
   }
   static int sum (int  numbers)
   {
      int total = 0;
      for (int i = 0; i < numbers.length; i++)
           total += numbers [i];
      return total;
   }
}

Look closely at BasicUses.java and you'll discover a second Tiger innovation: java.lang.StringBuilder. I use that class, instead of java.lang.StringBuffer, in the concatenation method because StringBuilder's lack of synchronization offers better performance than StringBuffer. (Why call a synchronized method and obtain the resulting performance hit, no matter how small, when it's not necessary?)

Tiger Uses Variable Arguments

As you've just seen, variable arguments are useful in simple methods. But they are even more useful in the Tiger SDK. That SDK uses variable arguments in the areas of reflection, process building, and formatting (and probably other areas that I have yet to discover.)

Reflection

java.lang.Class and a few java.lang.reflect classes (such as Method and Constructor) reveal methods that employ the new ... variable arguments syntax. Examples include Class's public Method getMethod(String name, Class ... parameterTypes) and Method's public Object invoke(Object obj, Object ... args). Those methods are callable, either in the traditional manner or in the new variable arguments manner. Consider an example where a classfile represents the class below:

class SomeClass
{
   public void someMethod (String strArg, int intArg)
   {
      System.out.println ("strArg = " + strArg);
      System.out.println ("intArg = " + intArg);
   }
}

Now suppose you want to dynamically load the SomeClass classfile
and reflectively invoke its solitary method. That task can be accomplished, in
the traditional manner, with the code fragment below:

Class [] argTypes =
{
   String.class,
   int.class
};

/* Note: Java 1.5's autoboxing language feature lets 
  you replace "new Integer (20)" with "20". The
  compiler converts "20" to "new Integer (20)".
  This code fragment assumes an earlier version
  of Java -- which is why "new Integer (20)" is 
  specified instead of "20".
*/
Object [] methodData =
{
   "A",
   new Integer (20) 
}; 
Class c = Class.forName ("SomeClass");
Method m = c.getMethod ("someMethod", argTypes);
m.invoke (c.newInstance (), methodData);In contrast, variable arguments let you express the code fragment above more
compactly, as follows:
Class c = Class.forName ("SomeClass");
Method m = c.getMethod ("someMethod", String.class, int.class);
m.invoke (c.newInstance (), "A", 20);
You save keystrokes and the code is much easier to read.

Process Building

The new java.lang.ProcessBuilder class makes it possible to build operating system processes and manage a collection of process attributes (the command, an environment, a working directory, and whether or not the error stream is redirected). One of that class's constructors and the public ProcessBuilder command(String ... command) method use the new variable arguments syntax to simplify the specification of a command for execution and its arguments. For example, to execute Windows' notepad program, and have that program load the autoexec.bat batch file from the root directory (on the current drive), specify the code fragment below:

Process p = new ProcessBuilder ("notepad", "\\autoexec.bat").start ();
The constructor specifies the command to execute, along with a variable number
of arguments to pass to the command. The start() method call
starts the command executing and returns a java.lang.Process
reference for retrieving process-exit status (in addition to other tasks).

Without variable arguments, you would probably specify the above code fragment in the following manner:

String [] commandAndArgs =
{
   "notepad",
   "\\autoexec.bat"
};
Process p = new ProcessBuilder (commandAndArgs).start ();Once again, variable arguments makes the code easier to read.

Formatting

Possibly the major reason for including variable arguments (and autoboxing) in Tiger is the new java.util.Formatter class. In combination with its java.lang.Appendable helper interface, Formatter formats data values of arbitrary data types and outputs the formatted results to arbitrary destinations.

Unless your application has specialized needs, you won't need to work directly with Formatter and Appendable. Instead, you'll work with one of the format methods found in the following classes: java.io.PrintStream, java.io.PrintWriter, and java.lang.String. Behind the scenes, those classes work with the Formatter class (and sometimes with Appendable, too).

PrintStream, PrintWriter, and String each present two format methods. One method takes a java.util.Locale argument, where the other method does not. The return types vary, as well. PrintStream's format methods return PrintStream references, PrintWriter's format methods return PrintWriter references, and String's format methods return String references. And finally, String's format methods are static methods, whereas the format methods in the other two classes are instance methods. The following code fragment demonstrates two of these format methods:

String s = String.format ("%.2f", 1.256);
System.out.format ("%05d", 1234);String's locale-less format method reveals a pattern
argument, consisting of %.2f ("format a floating-point value such
that there are exactly two digits after the decimal point, and employ rounding
if necessary"), followed by the floating-point value to format:
1.256. The formatted result -- 1.26 -- returns as a 
String, whose reference assigns to s.

Similarly, PrintStream's locale-less format method takes a pattern followed by a single value. However, the %05d pattern states that an integer is to be formatted to a minimum of five digits. If there are not enough digits, leading zeroes display to the left of the non-zero digits. Instead of returning the result -- 01234 -- for storage, PrintStream's format outputs 01234 to a stream (the standard output stream, in this case).

Note: java.text.MessageFormat also reveals a format method with a variable number of arguments. Unlike the previously discussed format methods, this format method is not a wrapper for Formatter.

C-style printf() and scanf()

Coming from a C background, I equate variable arguments with what are probably the most popular functions in C's standard library: printf() and scanf(). (It's a bit silly, but either function pops into my mind when someone mentions variable arguments.) For the uninitiated, C developers create formatted output by calling printf(), and obtain formatted input by calling scanf().

My fondness for those functions resulted in considerable pleasure when I found a pair of printf methods in each of the PrintStream and PrintWriter classes. It doesn't matter that they exist as convenience methods delegating to equivalent format methods. It's still nice to have official Java versions of printf().

Official versions of scanf() don't exist: scanf() relies upon pointers, which Java doesn't support. However, Tiger introduces a new java.util.Scanner class that makes up for the lack of scanf(). This class lets you create a simple regular expression- oriented text scanner, for scanning primitive types and strings from an input source.

The following FormattedIO.java source code demonstrates one of the printf methods and Scanner performing the equivalent of some commented-out C code.

FormattedIO.java
// FormattedIO.java
import java.util.Scanner;
class FormattedIO
{
   public static void main (String [] args)
   {
      /*
         // Execute the equivalent of the following
         // C code fragment.
         int i;
         float f;
         char s [50];
         printf ("Enter three values -- integer float string: ");
         scanf ("%d %f %s", &i, &f, s);
         printf ("%d %f %s\n", i, f, s);
      */
      System.out.printf ("Enter three values -- " +
                        integer float string: ");
      Scanner sc = new Scanner (System.in);
      int i = sc.nextInt ();
      float f = sc.nextFloat ();
      String s = sc.nextLine ();
      System.out.printf ("%d %f %s\n", i, f, s);
   }
}

After prompting the user to enter three values, FormattedIO creates a scanner that scans characters from standard input. The program next calls the methods nextInt(), nextFloat(), and nextString() to extract an integer, followed by a floating-point value, followed by a string of characters -- up to, but not including the line terminator -- from the standard input stream. Finally, System.out.printf ("%d %f %s\n", i, f, s); formats those values into a sequence of characters that it sends to the standard output.

Conclusion

Variable arguments are a subtle but quite useful feature in Tiger's arsenal of new language features. Uses range from simple methods to reflection, process building, and formatting. Perhaps the versatility of variable arguments comes out best in the new printf methods. Although scanf methods that use variable arguments (in the C sense) are not possible, Tiger's inclusion of a Scanner class makes up for that deficiency.

You really didn't think I'd let you get away without doing some homework, did you? I have a couple of exercises for you to work on. Answers will appear next month:

1. Is void foo (String ... args, int x) { } legal Java code? Why or why not?

2. Create a PrintFDemo application that demonstrates many of the formatting options made available by Formatter.

Next month, Java Tech enters the realm of zero sum perfect information games, such as chess.

Jeff Friesen is a freelance software developer and educator specializing in Java technology. Check out his site at javajeff.mb.ca.

ASCII码字符表

驯服 Tiger: 线程中的默认异常处理

如何处理未捕获的异常

John Zukowski （jaz@zukowski.net）
总裁, JZ Ventures, Inc.
2004 年 8 月

跟踪无法预期的运行时异常可能是一件又慢又费力的事情，只获得默认线程名称和堆栈跟踪通常是不够的。在驯服 Tiger 这一期专栏中，Java 开发人员 John Zukowski 向您展示了如何通过替代默认行为来定制输出。他还对比了通过细分 ThreadGroup 定制输出的老方法与通过提供自己的 UncaughtExceptionHandler 定制输出的新方法。

虽然我们不想创建在无法预期时抛出运行时异常的程序，但这种情况还是会发生——尤其是第一次运行复杂程序时。通常是使用默认行为、打印堆栈溢出和结束线程的生命来处理这些异常。

从哪里发现默认行为？每个线程都属于一个由 java.lang.ThreadGroup 类表示的线程组。顾名思义，线程组允许您将线程组合在一起。您可能是为了方便而将线程组合，例如，一个线程池中的所有线程都属于组 X，而另一个池的所有线程则属于组 Y，或者是为了访问控制而将线程进行组合。组 X 中的线程无权访问或改变组 Y 中的线程，除非它们都在同一线程组内（或在一个子组内）。

在 Tiger 之前，ThreadGroup 类提供了一种处理未捕获异常的方法：ThreadGroup 的 uncaughtException() 方法。如果异常不是 ThreadDeath，则将线程的名称和堆栈回溯（stack backtrace）发送到 System.err。但是 Tiger 添加了另一种方法：Thread.UncaughtExceptionHandler 接口。细分 ThreadGroup 或安装该新接口的实现都允许您更改默认行为。我们将对 Tiger 之前和之后提供的方法都进行研究。

使用 ThreadGroup 的定制行为
发生未捕获的异常时，默认行为是将堆栈溢出打印输出到系统错误（System.err）中，如清单 1 中所示。不需要使用任何命令参数来启动程序。

不使用任何参数运行该程序将生成清单 2 中的输出。尽管它不是一个很长的堆栈跟踪，但它是一个完整的堆栈跟踪。

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0   
at SimpleDump.main(SimpleDump.java:3)

正如 Java 平台的许多东西一样，如果不喜欢默认行为，您可以对其进行更改。在 Java 平台的 Tiger 版以前的版本中，不能替代所有线程的默认行为，但是可以创建一个新的 ThreadGroup，并更改在该组内创建的任何线程的默认行为。您可以重写 uncaughtException(Thread t, Throwable e) 方法来定制该行为。然后，当发生未预料的运行时异常时，该线程组内创建的任何线程都将获得新的行为。不过，最好是修复基础问题，我将提供一个简单的示例，说明更改默认行为所必需的步骤。清单 3 展示了将执行代码放入新线程的调整过的测试程序：

LoggingThreadGroup 类是一个新的内容，清单 4 中显示了它的定义。为了进行说明，通过重写 uncaughtException() 方法实现的特殊行为将在一个弹出窗口中显示该异常，这项操作是在特殊 Handler 的帮助下使用 Java Logging API 来完成的。

这里创建的定制 Handler 的类型为 LoggingWindowHandler，该类型的定义在清单 5 中。处理程序使用了一个支持类 LoggingWindow，该类将异常显示在屏幕上。清单 6 中显示了该类的定义。Handler 的 public void publish(LogRecord record) 方法实现了一些重要操作。其余操作大部分只与配置有关。

import java.util.logging.*;

public class LoggingWindowHandler extends Handler
{
    private static LoggingWindow window;
    private static LoggingWindowHandler handler;

    private LoggingWindowHandler()
    {
        configure();
        window = new LoggingWindow("Logging window", 400, 200);
    }

    public static synchronized LoggingWindowHandler getInstance()
    {
        if (handler == null)
        {
            handler = new LoggingWindowHandler();
        }
        return handler;
    }

    /** * Get any configuration properties set */
    private void configure()
    {
        LogManager manager = LogManager.getLogManager();
        String className = getClass().getName();
        String level = manager.getProperty(className + ".level");
        setLevel((level == null) ? Level.INFO : Level.parse(level));
        String filter = manager.getProperty(className + ".filter");
        setFilter(makeFilter(filter));
        String formatter = manager.getProperty(className + ".formatter");
        setFormatter(makeFormatter(formatter));
    }

    private Filter makeFilter(String name)
    {
        Filter f = null;
        try
        {
            Class c = Class.forName(name);
            f = (Filter) c.newInstance();
        }
        catch (Exception e)
        {
            if (name != null)
            {
                System.err.println("Unable to load filter: " + name);
            }
        }
        return f;
    }

    private Formatter makeFormatter(String name)
    {
        Formatter f = null;
        try
        {
            Class c = Class.forName(name);
            f = (Formatter) c.newInstance();
        }
        catch (Exception e)
        {
            f = new SimpleFormatter();
        }
        return f;
    } 
    
    // Overridden abstract Handler methods
    public void close()
    {
    }

    public void flush()
    {
    }

    /** * If record is loggable, format it and add it to window */
    public void publish(LogRecord record)
    {
        String message = null;
        if (isLoggable(record))
        {
            try
            {
                message = getFormatter().format(record);
            }
            catch (Exception e)
            {
                reportError(null, e, ErrorManager.FORMAT_FAILURE);
                return;
            }
            try
            {
                window.addLogInfo(message);
            }
            catch (Exception e)
            {
                reportError(null, e, ErrorManager.WRITE_FAILURE);
            }
        }
    }
}

执行 清单 3 中的 WindowDump 程序将出现图 1 中的屏幕。因为没有从 Logger 中删除控制台处理程序，所以堆栈溢出仍将出现在控制台上。

图 1. 记录的堆栈跟踪

发生运行时异常时，可能要做许多工作来更改发生的问题。该代码的大部分都是 Logging Handler，但是，要执行更改，就必须细分 ThreadGroup，重写 uncaughtException()，然后在该线程组中执行您的线程。不过，让我们通过只安装 Thread.UncaughtExceptionHandler，来看一看 Tiger 的处理方式。

使用 UncaughtExceptionHandler 的定制行为
对于 Tiger，Thread 类定义中添加了一个新的公共内部类 UncaughtExceptionHandler，更完整的名称为 Thread.UncaughtExceptionHandler（其他类访问内部类时需要使用完整名称）。接口的定义是一个方法，如图 7 中所示：

您可能没有注意到，清单 7 中的方法与我们前面重写的 ThreadGroup 的方法相同。实际上，现在由 ThreadGroup 类实现该接口。

新的内部类可以帮助我们了解下列两对新方法，并有助于我们在 Thread 中使用它们：

• getUncaughtExceptionHandler() 和 setUncaughtExceptionHandler()。
• getDefaultUncaughtExceptionHandler() 和 setDefaultUncaughtExceptionHandler()。

第一对方法是 getUncaughtExceptionHandler() 和 setUncaughtExceptionHandler()，它们允许您为当前线程及其后代定制行为，从而允许二十或更多的线程拥有自己的定制行为。不过，您更可能使用第二对方法 getDefaultUncaughtExceptionHandler() 和 setDefaultUncaughtExceptionHandler()。如果使用第二对方法设置默认处理程序，那么没有自己的异常处理程序的所有线程都将使用默认处理程序。

听起来好像很简单。为了进行说明，清单 8 转换了 清单 3 中的 ThreadGroup 友好的程序，使用新的 UncaughtExceptionHandler 接口：

该程序只是将 LoggingThreadGroup 重用为 UncaughtExceptionHandler，并没有创建新的处理程序实现。请注意，与原来的代码相比，新代码要简洁得多。

其他线程更改
Thread 类不仅支持使用 Tiger 添加的未捕获异常处理程序，它还支持使用 getAllStackTraces() 获得所有有效线程的堆栈跟踪，或者支持使用 getStackTrace() 来只获得当前线程的堆栈跟踪。这两种堆栈跟踪都返回类型为 java.lang.StackTraceElement 的对象，java.lang.StackTraceElement 是 Java 1.4 平台中添加的一个类，它可以让您生成自己的堆栈跟踪。同时，Java 5 平台新添加的功能是一个惟一线程标识符（可以使用 getId() 获得该标识符）和一个新的 Thread.State 类，以及与该类相关的 getThreadState() 方法。最后一个线程更改是一个状态枚举表，该表是用来监视系统状态，而不是用来同步状态的。

结束语
像 添加未捕获的异常处理程序这样的简单库更改，可以极大地增加原代码的可理解性。虽然在线程组级别上，新的库代码的功能与原来库代码的相同，但新模型中的易 用性和灵活性远远超出了将代码调整为更新的方式所需的时间。当然，老方法仍然可以使用，但最好将代码更新为最新的库功能。

[2] Page xvi

In the seventh line from the bottom, change "bugs fixes" to "bug fixes".

[6] Page 18

Change "You can download them from http://www.phptr.com/corejava." to "You can download them from http://horstmann.com/corejava."

[4] Page 25

In the NOTE, change "Environnment" to "Environment".

[6] Page 36

Change “it simply displays the string We will not use 'Hello, World'!” to “it simply displays the string We will not use 'Hello, World!'” (i.e. move the ! inside the quotes to match the program at the top of the page)

[5] Page 40

After "..you use a p, not an e, to denote the exponent." add: "The exponent is specified in decimal and denotes a power of two."

Page 40

Change NEGATIVE_ INFINITY to NEGATIVE_INFINITY (without a space)

[4] Page 41

Change "an unused 2048 byte-range" to "a range of 2048 unused values"

[6] Page 56

Change "Point your web browser to the docs/api/index.html subdirectory of your JDK installation." to "Point your web browser to the index.html file in the docs/api subdirectory of your JDK installation."

[6] Page 62, 123, 125, 465, 629, 630, 631, 640, 641, 642, 649, 681,

Change "Boolean" to "boolean" (in monospace)

[5] Page 62

Remove the line "^ Converts to upper case 0XCAFE". (This option was present in the Java 5 release candidate, but it was later dropped.)

[6] Page 63

Change "You use two a two-letter format..." to "You use a two-letter format..."

[4] Page 64

Last line of Table 3-7 (continued): Change E to Q.

[2] Page 80 BigIntegerTest.java line 8

Change Scanner.create to new Scanner

[4] Page 85

Change System.out.print(" " + a[i]); to System.out.print(" " + args[i]);

[4] Page 86

Change "Initially that is just r itself, but ..." to "Initially that is just r + 1, but..."

[4] Page 89 CompoundInterest.java line 5

Change final int STARTRATE to final double STARTRATE

[6] Page 95

Change "Encapsulation (sometimes called data hiding) is a key concept in working with objects. Formally, encapsulation is nothing more than combining data and behavior in one package and hiding the implementation of the data from the user of the object." to "Encapsulation (sometimes called information hiding) is a key concept in working with objects. Formally, encapsulation is nothing more than combining data and behavior in one package and hiding the implementation details from the user of the object."

[4] Page 95

Change "When you invoke a message on an object" to "When you invoke a method on an object"

[6] Page 96

Change "Thus, a class depends on another class if its methods manipulate objects of that class." to "Thus, a class depends on another class if its methods use or manipulate objects of that class."

[4] Page 104-106 CalendarTest.java

The program prints an unsatisfactory calendar in locales whose first day of the week is not Sunday. (In most parts of the world, the first day of the week is considered Monday--after all, Saturday and Sunday are the weekend.) The following changes take care of this:

• Remove the header SunMon Tue Wed Thu Fri Sat on page 104
• In the program listing, replace lines 18 and 19 with
  

   // get first day of week (Sunday in the U.S.)
   int firstDayOfWeek = d.getFirstDayOfWeek();

• In lines 22 and 49, replace Calendar.SUNDAY with firstDayOfWeek
• Add the following four lines before the } in line 44. (The first line is blank)
  

  
   // start a new line at the start of the week
   if (weekday == firstDayOfWeek)
   System.out.println();
  

• Remove lines 36 through 39

[4] Page 105

Change "For each day, we print a space if the day is < 10, then the day, and then a * if the day equals the current day." to "The current day is marked with a *."

[6] Page 106

In the Note, remove "and the hard-wired assumption that the week starts on a Sunday"

[6] Page 121

Change "demonstate" to "demonstrate"

[6] Page 128, 129

Change "Booleans" to "boolean values" (note monospace)

[6] Page 135

Remove the sentence "The sole purpose of package nesting is to manage unique names."

[6] Page 141

Change "Recall that you can import public classes only from other packages." to "Recall that you can import only public classes from other packages."

[4] Page 141

In the third line from the bottom, change "packages" to "package".

[4] Page 143

In the last line, change "set the warning border" to "set the warning string".

[6] Page 147

Change "If you like, you can place hyperlinks to other classes or methods anywhere in any of your comments." to "If you like, you can place hyperlinks to other classes or methods anywhere in any of your javadoc comments."

[6] Page 155

Remove "(that is, when i is 1 or 2)" and "(when i is 0)" , so that the remaining clause is "either Employee or Manager".

[6] Page 165

Change "In particular, move common fields and methods (whether abstract or not) to the abstract superclass." to "Move common fields and methods (whether abstract or not) to the superclass (whether abstract or not)."

[6] Page 172

In the numbered list, add 4. before "Compare the classes of this and otherObject." Increment the following numbers.

[4] Page 172

Remove "Judging from this evidence. . ." until the end of the note.

[4] Page 173

In Table 5-1, change the Hash Code column from 140207504 / 140013338 / 884756206 to 69609650 / 69496448 / -2141031506

[4] Page 174

In Table 5-2, change 3030 to 2556 (2x)

[6] Page 179

Change the last word on the page from "classed" to "called"

[6] Page 180/181

Change "relocation/tions/ting" to "reallocation/tions/ting" (3x)

[6] Page 181

Change "(This is different from, and, of course, never larger than, the array list’s capacity.)" to "(This is of course never larger than the array list’s capacity.)"

[6] Page 188

Change "returns a new Integer object initialized to the integer’s value, assuming the specified String represents" to "returns a new Integer object initialized to the integer whose digits are contained in the string s. The string must represent" (2x)

[4] Page 189

Change

System.out.printf("%d %d", new Object[] { new Integer(d), "widgets" } );

to

System.out.printf("%d %s", new Object[] { new Integer(n), "widgets" } );

[6] Page 191

Remove "We discuss reflection in the next section."

Page 193

Change "all fields, operations, and constructors" to "all fields, methods, and constructors"

[6] Page 198

Change the last line from

while (cl != Object.class);

to

while (cl != null);

[6] Page 199

Remove line 3 (import java.text.*;)

[6] Page 201

Change "arrayCopy" to "arraycopy"

[6] Page 203/204

Change "fundamental" to "primitive" (2x)

[4] Page 206

Change

System.out.printf("%10.4f | %10.4f%n" + y, x, y);

to

System.out.printf("%10.4f | %10.4f%n", x, y);

[4] Page 207

Remove code lines 42 and 43.

[4] Page 215

Change the first java.lang.Comparable API header to java.lang.Comparable<T>. Remove the second java.lang.Comparable<T> header.

[4] Page 220 and 221

In the clone methods, change

return super.clone();

to

return (Employee) super.clone();

Page 221

Change

public Object clone() throws CloneNotSupportedException

to

public Employee clone() throws CloneNotSupportedException

[6] Page 228

Change “Because the TalkingClock defines no constructors” to “Because the TimePrinter class defines no constructors”

[4] Page 231

In the NOTE, change

java ReflectionTest 'TalkingClock$TimePrinter'

to

java ReflectionTest TalkingClock\$TimePrinter

(that is, remove the quotes and add a backslash). Both methods work, but the change matches the preceding text.

[6] Page 233

Change “Note that the TimePrinter class no longer needs to store a beep instance variable. It simply refers to the parameter variable of the method that contains the class definition.” to “Note that the TalkingClock class no longer needs to store a beep instance field. The actionPerformed method of the TimePrinter class simply refers to the beep parameter variable of the start method.”

[4] Page 233 (2x) and 235 (1x)

Change

Timer t = new Timer(1000, listener)

to

Timer t = new Timer(interval, listener)

[4] Page 254

Change /**import java.awt.* to import java.awt.*

[6] Page 251

Change frame.show(); to frame.setVisible(true);

Page 281

Change javax.swing.ImageIO to javax.imageio.ImageIO

[4] Page 330

In the API note for getActionMap, change "keystrokes to action keys" to "arbitrary objects to Action objects".
In the API note for getInputMap, change "action keys to action objects" to "keystrokes to arbitrary objects"

[4] Page 330

Change released ctrl Y to ctrl released Y

[4] Page 343

Change "Each user interface has a wrapper class..." to "Each user interface component has a wrapper class...".

[4] Page 349

Change "Finally, you add the individual buttons" to "Finally, you add the panel"

[4] Page 349

The word add in "using the add method you have seen before" is in the wrong font.

[4] Page 353

In the first API note, change int cols to int columns

[4] Page 360

Remove code lines 66 - 68

[4] Page 400

Change the four code lines starting with

JSpinner timeSpinner

to

JSpinner timeSpinner = new JSpinner(new 
      SpinnerDateModel(new Date(), null, null, Calendar.HOUR)
      { 
         public void setCalendarField(int field) {} 
      });

[4] Page 402

Change code lines 75 - 78 to
      JSpinner timeSpinner = new JSpinner(new
            SpinnerDateModel(new Date(), null, null, Calendar.HOUR)
            {
               public void setCalendarField(int field) {}
            });

[4] Page 405

In the explanation for the maximum parameter of the javax.swing.SpinnerDateModel constructor, change "The maximum valid value, or null if no lower bound..." to "The maximum valid value, or null if no upper bound..."

[4] Page 412

In the second line from the bottom, change JPopup to JPopupMenu.

[4] Page 422

Below line 28, add a line

add(panel, BorderLayout.CENTER);

[4] Page 432

Change

panel.add(style, bold);

to

panel.add(component, constraints);

[6] Page 443

The bulleted list is wrong (with different errors in two printings). Here is the correct version:

• Connecting the west side of the component with the west side of the container;
• Traversing the width of the component;
• Connecting the east side of the component with the west side of the container.

[4] Page 444

Change

Spring.max(layout.getConstraints(faceLabel).getWidth(),
Spring.max(layout.getConstraints(sizeLabel).getWidth()));

to

Spring.max(layout.getConstraints(faceLabel).getWidth(),
layout.getConstraints(sizeLabel).getWidth()));

(i.e., remove the second Spring.Max()

[4] Page 447

Change "...to the given side of the start container" to "...to the given side of the startcomponent"

[4] Page 457

Change "The icon is a warning icon" to "The icon is a question icon". Change WARNING_MESSAGE to QUESTION_MESSAGE

[6] Page 509

Change “NOTE: The strings used when you define the parameters with the param tag and those used in the getParameter method must match exactly. In particular, both are case sensitive.” to “NOTE: A case-insensitive comparison is used when matching the name attribute value in the param tag and the argument of the getParameter method.”

[6] Page 522, 524

Change

public Enumeration getApplets() { return null; } 

to

public Enumeration<Applet> getApplets() { return null; } 

and

public Iterator getStreamKeys() { return null; }

to

public Iterator<String> getStreamKeys() { return null; }

Page 527

Change

Main-Class: com/mycompany/mypkg/MainAppClass

to

Main-Class: com.mycompany.mypkg.MainAppClass

[6] Page 547

Change

defaultSettings.put("color.red", "0 50 50");

to

defaultSettings.put("color.red", "0");

[4] Page 567

Change se.setCause(e) to se.initCause(e)

[4] Page 571

Change the numbers after StackTraceTest.java: from 8 23 / 8 14 23 / 8 14 14 23 to 17 33 / 17 23 33 / 17 23 23 33

[6] Page 602

Change

java -Dcom.sun.management.jmxremote MyProgram.java

to

java -Dcom.sun.management.jmxremote MyProgram

[6] Page 604

Change void addXxxListener(XxxEvent) to void addXxxListener(XxxListener).

[4] Page 615

Change "displays all instance fields of the evt variable" to "displays all instance fields of the event variable"

[4] Page 630

In the second line of Table 12-2, change b₁₇a₁₆a₁₅... to b₁₇b₁₆a₁₅...

[6] Page 632

Change “The advantage of having the RandomAccessFile class implement both DataInput and DataOutput is that this lets you use or write methods whose argument types are the DataInput and DataOutput interfaces.” to “The RandomAccessFile class implements both DataInput and DataOutput. It is a good idea to use these interfaces for method parameters.”

[4] Page 634

Change Set<String, CharSet> to Map<String, CharSet>.

[5] Page 639

In the API description for CharBuffer decode(ByteBuffer buffer), change "decodes the given character sequence ..." to "decodes the given byte sequence"

[4] Page 658

In the second line from the bottom, change long int nbytes to long nbytes.

[4] Page 660

Lines 76, 77 of the code should be
      Raises the salary of this employee.
      @param byPercent the percentage of the raise

[4] Page 667

Change "The java.util.Date class defines its own readObject/writeObject methods" to "The serializable java.util.Date class defines its own writeObject method". (The wording in the book was correct, but it confused some readers into thinking that Date is externalizable.)

[4] Page 688

In the documentation for createNewFile, change "automatically creates" to "atomically creates".

[4] Page 713

In the second line of the section Generic Code and the Virtual Machine, change "was even able compile" to "was even able to compile".

[4] Page 719

In the third line from the top, change new Pair<String>(10) to new Pair<String>[10]

[4] Page 720

In the tenth line from the bottom, change

								Pair<Employee> = ArrayAlg...
						

to

Pair<Employee> result = ArrayAlg...

[6] Page 723

Change
void set(? super Manager)
? super Manager get()
to
void setFirst(? super Manager)
? super Manager getFirst()

[6] Page 723

Change "with any Manager object (or a subtype such as Executive), but not with an Employee" to "with any value of type Manager, Employee, or Object, but not with a subtype value such as Executive."

[6] Page 726

Change “Of course, in this case, we were not compelled to use a wildcard—there is nothing wrong with using a type parameter, as in the swapHelper method.” to “Of course, in this case, we were not compelled to use a wildcard. We could have directly implemented <T> void swap(Pair<T> p) as a generic method without wildcards.”

[4] Page 735

Add an entry

enum

an enumerated type

3

[6] Page 743

Change "Boolean, 42, 46, 186, 735" to two entries "boolean, 42, 46, 735" and "Boolean, 186"

[6] Page 760

Change "true or false, seeBoolean" to "true or false, seeboolean"

Seventh Edition Volume 2 (JDK 5.0)

[3] Page xvii

In the second line from the bottom, change Example 5-8 to Example 5-12

[4] Page 3

Change "inside the move method of the Ball class." to "inside the addBall method of the BounceFrame class".

Page 12 BounceThread.java

Remove these lines:

203. public static final int STEPS = 1000;
204. public static final int DELAY = 3;

[3] Page 19

Change "of its parent thread, that is, the thread that started it" to "of the thread that constructed it"

[2] Page 30

Change "You must make sure that the thread cannot be interrupted between the test and the insertion." to "You must make sure that no other thread can modify the balance between the test and the transfer action."

[2] Page 40

Remove the first four lines after Synchronized Blocks "However, a Java object ... only one condition".

[2] Page 41

Apply boldface to synchronized (lock) and remove it from System.out.println(. . .)

[2] Page 42

Change $1,200 to $200 and $1,300 to $300

[2] Page 43

In Figure 1-6, change 1200 to 200 and 1300 to 300

[3] Page 49

Change "The call Object head = q.poll(...) returns true for 100 milliseconds ..." to "The call Object head = q.poll(...) tries for 100 milliseconds ..."

[2] Page 64

In the code just above the API notes, change taks.size() to tasks.size().

[4] Page 100

In the API notes for the remove method of java.util.List<E>, change "removes and returns an element at the specified position" to "removes and returns the element at the specified position"

[4] Page 100

In the API notes for java.util.List<E>, add the following before E set(int i, E element):

• E get(int i)
  returns the element at the specified position.

Page 110

Change "construct a tree set" and "constructs a tree set" to "constructs a priority queue".

[3] Page 130 Code line 98

Change

return offset < elements.length;

to

return offset < count; 

[4] Page 152, 153 ThreadedEchoServer.java

Remove lines 43, 86. Change the following lines:

22. Runnable r = new ThreadedEchoHandler(incoming);
44. public ThreadedEchoHandler(Socket i)
47. incoming = i;

[4] Page 166

In the API note of void setConnectTimeout(int timeout)/int getConnectTimeout(), change "...the read method of the associated input stream..." to "...the connect method of the associated input stream...". In the API note of void setReadTimeout(int timeout)/int getReadTimeout(), change "...the connect method of the associated input stream..." to "...the read method of the associated input stream...".

Page 175

The Scanner class wraps the InterruptedIOException. For greater clarity, change
Scanner in = new Scanner(s.getInputStream()); String line = in.nextLine();
to
InputStream in = s.getInputStream();// read from in

[2] Page 229

Change "gets a description of all tables in a catalog..." to "returns a description of all tables in a catalog..."

[2] Page 229

Change "The catalog and schema parameters..." to "The catalog and schemaPattern parameters..."

[3] Page 240

Change

stat.releaseSavepoint(svpt) 

to

conn.releaseSavepoint(svpt)

[2] Page 244

In the last two rectangles in the bottom row of Figure 4-9, change ou=people to ou=groups

[4] Page 281

Product.java is the wrong version. The companion code has the correct version, but it is too long to fit in its entirety. Use this abbreviated version:

import java.rmi.*;

public interface Product extends Remote
{ 
   /**
      Gets the description of this product.
      @return the product description
   */
   String getDescription() throws RemoteException;

   final int MALE = 1;
   final int FEMALE = 2;
   final int BOTH = MALE + FEMALE;
}

[4] Page 282

ProductImpl.java is the wrong version. The companion code has the correct version, but it is too long to fit in its entirety. Use this abbreviated version:

import java.rmi.*;
import java.rmi.server.*;

public class ProductImpl extends UnicastRemoteObject implements Product
{ 
   public ProductImpl(String n, int s, int age1, int age2, String h) throws RemoteException
   {  
      name = n;
      ageLow = age1;
      ageHigh = age2;
      sex = s;
      hobby = h;
   }

   public boolean match(Customer c)
   {  
      if (c.getAge() < ageLow || c.getAge() > ageHigh)
         return false;
      if (!c.hasHobby(hobby)) return false;
      if ((sex & c.getSex()) == 0) return false;
      return true;
   }

   public String getDescription() throws RemoteException
   {  
      return "I am a " + name + ". Buy me!";
   }

   private String name, hobby;
   private int ageLow, ageHigh, sex;
}

[3] Page 293

Change

name = (String) data.get();; 

to

name = (String) data.get();

[4] Page 294, 295

ProductImpl.java is the wrong version. The companion code has the correct version, but it is too long to fit in its entirety. Use this abbreviated version:

import java.io.*;
import java.rmi.*;
import java.rmi.activation.*;

public class ProductImpl
   extends Activatable
   implements Product
{ 
   /**
      Constructs a product implementation
      @param id the activation id
      @param data the marshalled construction parameter (containing the product name)
   */
   public ProductImpl(ActivationID id, MarshalledObject data) 
      throws RemoteException, IOException, ClassNotFoundException
   {  
      super(id, 0);
      name = (String) data.get();
      System.out.println("Constructed " + name);
   }

   public String getDescription() throws RemoteException
   {  
      return "I am a " + name + ". Buy me!";
   }

   private String name;
}

[4] Page 296

Change

static Remote register(ActivationDescriptor desc)

to

static Remote register(ActivationDesc desc)

[4] Page 311

Change

System.out.println(orb.object_to_string(impl));

to

System.out.println(orb.object_to_string(ref));

[2] Page 334

Remove the line

JLabel label = new JLabel();

[4] Page 391

Add return this; as the last line of getTableCellRendererComponent so that the code looks like this:

class ColorTableCellRenderer extends JPanel implements TableCellRenderer
{
   public Component getTableCellRendererComponent(JTable table, Object value, boolean isSelected,
      boolean hasFocus, int row, int column)
   {
      setBackground((Color) value);
      if (hasFocus)
         setBorder(UIManager.getBorder("Table.focusCellHighlightBorder"));
      else
         setBorder(null);
return this;
   }
}

[2] Page 425

Change "on the CD" to "in the companion code"

[3] Page 439

In Fig. 6-48, change the callout "minimize icon" to "maximize icon"

[4] Page 443

Change “The JDesktopPane class has no method to return the selected frame. Instead, you must traverse all frames ...” to “Traverse all frames ...”. (Actually, you can get the selected frame by calling JDesktopPane.getSelectedFrame, but we need its index.)

[4] Page 462

Change "... drawn by the CubicCurve3D class ..." to "... drawn by the CubicCurve2D class ..."

[3] Page 462

Change "between 2180 and 180" to "between -180 and 180"

Page 600

Change DndConstants to DnDConstants

[3] Page 664

Example 8-10: ChartBean2BeanInfo.java has the wrong file. The correct file is

package com.horstmann.corejava;

import java.awt.*;
import java.beans.*;

/**
 The bean info for the chart bean, specifying the 
 icons and the customizer.
*/
public class ChartBean2BeanInfo extends SimpleBeanInfo
{ 
 public BeanDescriptor getBeanDescriptor()
 { 
 return new BeanDescriptor(ChartBean2.class, ChartBean2Customizer.class);
 }

 public Image getIcon(int iconType)
 { 
 String name = "";
 if (iconType == BeanInfo.ICON_COLOR_16x16) name = "COLOR_16x16";
 else if (iconType == BeanInfo.ICON_COLOR_32x32) name = "COLOR_32x32";
 else if (iconType == BeanInfo.ICON_MONO_16x16) name = "MONO_16x16";
 else if (iconType == BeanInfo.ICON_MONO_32x32) name = "MONO_32x32";
 else return null;
 return loadImage("ChartBean2_" + name + ".gif");
 }
}

[4] Page 705

Change http://bugs.sun.com/developer/bugParade/bugs/4030988.html to http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4030988

[4] Page 772

Change

int outputSize= cipher.getOutputSize(inLength);

to

int outputSize= cipher.getOutputSize(blockSize);

[3] Page 788

In the fourth line from the bottom, change "the java.text class" to "the java.textpackage"

[3] Page 807

In the 4th line from the bottom (excluding the CAUTION note), change 10.0E7 to 10.0E8.

[4] Page 811

Change java -encoding Big5 Myfile.java to javac -encoding Big5 Myfile.java.

[2] Page 833

In line 17 of the code for HelloNative.h, change ifdef to #ifdef

[3] Page 836

Change
... a format string "%w.pf" ...
to
... a format string "%w.pf" ...
(w and p should be Roman italic)

[2] Page 861

Change

jint ThrowNew(JNIEnv *env, jclass clazz, const char msg[])

to

jint ThrowNew(JNIEnv *env, jclass cl, const char msg[])

[3] Page 878

Change GetSuperClass to GetSuperclass

[3] Page 927

Change "XML Style Sheet Transformations" to "Extensible Stylesheet Language Transformations"

[4] Page 935

In Figure 12-8, change the rightmost “XML Document” to “Transformed Document (HTML, text, ...)”

Thanks to Joe Abounader, Jerry Agin, Stefan Alfbo, Stefan Badstübner, Alan Bellanger, Bob Boritz, Eric Cauchon, Davide Cecchetto, Jerry Chen, Philip Copp, Sandu Crasteti, Bernard Desruisseaux, Edward H. Fabrega, Gabriel Florit, Angelo Furfaro, Dan Gamel, Mahesh Gopalan, Derek Haines, Patrick J. Henry, Roger House, Elliott Hughes, Alessandro Iacopini, Jon Kendall, Sven Kirsimäe, Jim Jennings, Geert Kloosterman, Jeffrey Knauth, Jason Leasure, Mark Lawrence, Joyce Lee, James Litchfield, Bingwei Liu, Simon Margulies, Miguel Martinez, Charlie Mason, Mick McCarthy, Carlos Montejo, Nick Morrott, Michele Nesta, Elizabeth Norval, Evelyn Obaid, Peter Olsen, Petr Panteleyev, Andrei Radu, Terry Roe, Avi Schwartz, Jeff Schwarz, Burak Sevindi, Juan Silva, Russell Smith, Jigar Shah, William So, Thomas Stark, Mel Sumrell, Yves Thorrez, Joe Toomey, Michael J. Young, Michael Zeidler, and (your name might go here) for their bug reports!

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1695004

Java不是完美的，Java的不足除了体现在运行速度上要比传统的C++慢许多之外，Java无法直接访问到操作系统底层（如系统硬件等)，为此Java使用native方法来扩展Java程序的功能。
　　可以将native方法比作Java程序同Ｃ程序的接口，其实现步骤：
　　１、在Java中声明native()方法，然后编译；
　　２、用javah产生一个.h文件；
　　３、写一个.cpp文件实现native导出方法，其中需要包含第二步产生的.h文件（注意其中又包含了JDK带的jni.h文件）；
　　４、将第三步的.cpp文件编译成动态链接库文件；
　　５、在Java中用System.loadLibrary()方法加载第四步产生的动态链接库文件，这个native()方法就可以在Java中被访问了。

CONTENTS

• What Is a Native Method?
• Uses for Native Methods
• Benefits and Trade-Offs
• How Does This Magic Work?
• Summary

The goal for this chapter is to introduce you to Java's native methods. If you are new to Java, you may not know what native methods are, and even if you are an experienced Java developer, you may not have had a reason to learn more about native methods. At the conclusion of this chapter you should have a better understanding of what native methods are, when and why you may want to use them, and the consequences of using them. You should also have a basic understanding of how native methods work. You will then be more than ready to tackle the next three chapters, which dive into the nitty-gritty details of Java's Native Methods.

What Is a Native Method?

Simply put, a native method is the Java interface to non-Java code. It is Java's link to the "outside world." More specifically, a native method is a Java method whose implementation is provided by non-Java code, most likely C (see Figure 30.1). This feature is not special to Java. Most languages provide some mechanism to call routines written in another language. In C++, you must use the extern "C" stmt to signal that the C++ compiler is making a call to C functions. It is common to see the qualifier pascal in many C compilers to signal that the calling convention should be done in a Pascal convention, rather than a C convention. FORTRAN and Pascal have similar facilities, as do most other languages.

Figure 30.1 : A native method is a Java method whose implementation is provided by non-java code.

In Java, this is done via native methods. In your Java class, you mark the methods you wish to implement outside of Java with the native method modifier-much like you would use the public or static modifiers. Then, rather than supplying the method's body, you simply place a semicolon in its place. As an example, the following class defines a variety of native methods:

public class IHaveNatives
{
  native public void Native1( int x ) ;
  native static public long Native2() ;
  native synchronized private float Native3( Object o ) ;
  native void Native4( int[] ary ) throws Exception ;
}

This sample class shows a number of possible native methods. As you may have noticed, native methods look much like any other Java method, except a single semicolon is in the place of the method body. Naturally, the body of the method is implemented outside of Java. What you basically define is the interface into this external method. This method declaration describes the Java view of some foreign code.

The only thing special about this declaration is that the keyword native is used as a modifier. Every other Java method modifier can be used along with native, except abstract. This is logical, because the native modifier implies that an implementation exists, and the abstract modifier insists that there is no implementation. Your native methods can be static methods, thus not requiring the creation of an object (or instance of a class). This is often convenient when using native methods to access an existing C-based library. Naturally, native methods can limit their visibility with the public, private, private protected, protected, or unspecified default access. Native methods can also be synchronized (see Chapter 7, "Concurrency and Synchronization"). In the case of a synchronized native method, the Java VM will perform the monitor locking prior to entering the native method implementation code. So, as in Java, the developer is not burdened with doing the actual monitor locking and unlocking.

The example uses a variety (although not all) of types. This is because a native method can be passed any Java type. There is no special procedure within the Java code to pass data to the native method. However, the developer of native methods must be careful that his native methods behave properly when manipulating Java datatypes. Native methods do not undergo the same kinds of checking as a Java method, and they can easily corrupt a Java datatype if care is not taken (see Chapter 31, "The Native Method Interface").

A native method can accept and return any of the Java types-including class types. Of course, the power of exception handling is also available to native methods. The implementation of the native method can create and throw exceptions similar to a Java method. When a native method receives complex types, such as class types (such as Object in the example) or array types (such as the int[] in the example), it has access to the contents of those types. However, the method used to access the contents may vary depending on the Java implementation being used. The major point to remember is that you can access all the Java features from your native implementation code, but it may be implementation-dependent and will surely not be as convenient or easy as it can be done from Java.

The presence of native methods does not affect how other classes call those methods. The caller does not even realize it is calling a native method, so no special code is generated, and the calling convention is the same as for any other method-the calling depends on the method being virtual or static. The Java virtual machine will handle all the details to make the call in the native method implementation. One minor exception may be with the methods marked with the final modifier. The Java implementation may take advantage of a final method and choose to inline its code. It would be doubtful that this could be achieved with a native final method, but this is an optimization issue, not one of functionality. When a class containing native methods is subclassed, the subclass will inherit the native method and also will have the capability of overriding the native method-even with a Java method (that is, the overridden method can be implemented in Java). If a native method is also marked with the final modifier, a subclass is still prevented from overriding it.

Native methods are very powerful, because they effectively extend the Java virtual machine. In fact, your Java code already uses native methods. In the current implementation from Sun, native methods are used in many places to interface to the underlying operating system. This enables a Java program to go beyond the confines of the Java Runtime. With native methods, a Java program can virtually do any application level task.

Uses for Native Methods

Java is a wonderful language to use. However, there are times when you either must interface with existing code, can't express the task in Java, or need the absolute best performance.

Accessing Outside the Java Environment

There are times where a Java application (or applet) must communicate with the environment outside of Java. This is, perhaps, the main reason for the existence of native methods. For starters, the Java implementation will need to communicate with the underlying system. That underlying system may be an operating system such as Solaris or Win32, or it may be a Web browser, or it may be custom hardware, such as a PDA, Set-top-device, and so forth. Regardless of what is under Java, there must be a mechanism to communicate with that system. At some point in a Java program, there will be that point where Java meets the outside world, an interface between Java and non-Java worlds. Native methods provide a simple clean approach to providing this interface without burdening the rest of the Java application with special knowledge.

Accessing the Operating System

The Java virtual machine describes a system that the Java program can rely on to be there. This virtual machine supports the Java Language and its runtime library. It may be composed of an interpreter or can be libraries linked to native code. Regardless of its form, it is not a complete system and often relies on an existing system underneath to provide a lot of support. More than likely, a full-fledged operating system, such as Solaris or Win32, resides beneath it. The use of native methods enables the Java Runtime to be written in Java yet have access to the underlying operating system, or even the parts of the Java virtual machine that may be written in a language such as C. Further, if a Java feature does not encapsulate an operating system feature needed by an application, native methods can be used to access this feature.

Embedded Java

It is conceivable to see a Java virtual machine embedded inside another program. Several WWW browsers come to mind. Perhaps this enclosing program is not implemented in Java. The Java Runtime may need to access the enclosing program for services to support the Java environment. Once again, native methods provide a clean interface for this access to the surrounding program. Furthermore, the vendor of the program may wish to expose some features of the program to a Java applet. The vendor would simply need to create a set of Java classes containing native methods, which provide the interface for the Java application into the program. The native method implementation would then be the "glue" between the Java applet and the internals of the enclosing program.

Custom Hardware

Another important possible application of native methods being used to access a non-Java world is providing Java programs access to custom hardware. Perhaps a Java virtual machine is running within a PDA or Set-Top-Device. A lot of what would normally be in an operating system may exist in hardware or software embedded in ROM, or other custom chip sets. Another possibility is that a computer may be equipped with a dedicated graphics card. It would be ideal to have Java make use of the graphics hardware. A set of Java classes with native methods defined would provide the Java program access to these features.

Sun's Java

In the current implementation from Sun, the Java interpreter is written in C and can thus talk to the outside environment as any normal C program can. A majority of the Java Runtime is written in Java and may make calls into the interpreter or directly to the outside environment, all via native methods. The application deals mostly with the Java Runtime, but it may also talk to the outside environment via native methods. For example in the class java.lang.Thread the setPriority() method is implemented in Java but calls the method setPriority0(), which is a native method in the Thread class. This native method is implemented in C and resides within the Java virtual machine itself. On the Windows 95 platform this native method will then call (eventually) the Win32 SetPriority() API. This is an example where the native method implementation was provided by the Java virtual machine directly. In most cases the native method implementation resides in an external dynamic link library (discussed in a following section), but the call still goes through the Java virtual machine.

Performance

Another major reason for native methods is performance. The Java language trades some performance for features like its dynamic nature, garbage collecting, and safety. Some Java implementations, like the current crop, may be interpreters, which also add extra overhead. The lost performance can be small as the implementation technology for Java systems improve, but until then and even after there may always be a small performance overhead for certain functionality a Java program may need. This functionality can be pushed down into a native method. That native method can then be implemented efficiently at the native lower level of the system on which the Java virtual machine is running. Once at the native implementation level, the developer can use the best-suited language, such as C or even assembler. In this way, maximum performance can be achieved in those specific areas while the bulk of the application is done within the safe and robust Java virtual machine. One area where you may choose to implement some parts of an application in native methods is time-intensive computations, such as graphics rendering, simulation models, and so forth.

Accessing Existing Libraries

The fact that Java is targeted at the production of platform-neutral code means that the current implementations may not access system features that you may need. An example is a database engine. If you need to, you can use the native method facility to provide your own interface to such libraries. Further, you may want to use Java to write applications that use existing in-house libraries. Again, the use of native methods enables you to make such an interface. This enables you to leverage off your existing code base as well as gradually introduce Java-based applications among your other applications coded in an older language.

Benefits and Trade-Offs

The presense of native methods offers many benefits, the biggest being the extension of Java power. However, there is always a downside to all good things, and native methods definitely have their downsides. Depending on what the goals of your application are, the downsides may not be that terrible. Foremost is the fact that, by definition, the use of native methods defeats several of Java's main goals: platform neutrality, system safety, and security.

Some of Java's attractive features help minimize the downsides, however. The best feature of all is that Java is such a nice language to develop in you won't want to use native methods unless you have to.

Platform Neutrality

Because a native method is implemented in a foreign language, the platform neutrality is limited to the language being used. Most likely, native methods are implemented in C or C++. Although those languages have standards, these standards leave a lot of room for implementation-defined attributes (even compilers on the same system may differ), so your mileage may vary. If the native method accesses the underlying system, you are tying your implementation to that system. For example, the file systems of UNIX and Win32 have some differences. There may even be differences between flavors of UNIX and Win32 (Win95 and WinNT are not identical). Once again, you may sacrifice your platform neutrality with your native method. This may cause you to have to support a limited number of platforms (rather than all Java platforms). Further, for each platform you choose to support, you may (probably will) have to implement several flavors of the native method.

The Java language and runtime provide a number of features that make applications more robust and safe. Java's memory management, synchronization features, and lack of address manipulation help prevent common programming mistakes from slipping through the development and testing phases of your product. However, once you drop out of Java into a native method, you are, once again, at the mercy of the language and system in which you are implementing the native method. If your native method implemented in C chooses to manipulate an address directly, you risk corrupting some part of memory, perhaps even the Java virtual machine itself.

Security Concerns

Additionally, the Java Language provides features to aid in the writing of secure applications. A Java virtual machine is much more capable of detecting an "evil" Java program than an application in other languages. Once you drop into a native method, the Java virtual machine can no longer verify, catch, or prevent the program from violating the security of the environment in which the Java virtual machine is running. This is the reason a Java-enabled Web browser typically does not allow a nontrusted native method to be called. In today's browsers, a trusted native method must be present on the local system in a certain location to be executed from an arriving applet (in other words, one loaded from a remote site). For more information on security, in general, see Part 6, "Security." For more information on how security applies to native methods, see Chapter 33, "Securing Your Native Method Libraries."

System Safety

Another potential hazard is the fact that a native method is not isolated. When a native method is entered, it not only accesses the environment outside the Java virtual machine, it also freely accesses the Java virtual machine directly. This is a necessary evil. It gives the native method quite a bit of power and flexibility, because it may need access to information kept within the virtual machine to do its job. This flexibility, however, exposes the internals of the Java virtual machine to the native method.

Dependence on the Java Implementation

It should be obvious that the implementation of native methods is also dependent on the Java implementation itself. This means that the native methods you write today for use with the Sun implementation of Java may not work with a Java implementation from another vendor.

The interface used for the Java virtual machine to call out to native methods and the interface that native methods use to access the internal functions and data structures of the Java virtual machine are not, currently, defined by either the Java Language Specification or the Java Virtual Machine Specification. A lot of native methods call back into the Java virtual machine for instantiating new objects, calling Java methods, throwing Java Exceptions, and so forth. Further, the method used to lay out Java types is also not defined. So, although your native method of today knows how to access the fields of an object, this could be different on the Java virtual machine of tomorrow. This oversight can be greatly helped if a standard API is defined for both how a Java program interacts with a native method and how a native method accesses data within the Java virtual machine. Even after such an API, implementation-defined behavior will likely still be present.

Java to the Rescue!

Recall that Java helps to minimize the damage of native methods. When you find yourself in the position that you must use native methods, you can take advantage of Java's features to help isolate the usage and perhaps maintain a fair amount of Java's advantages.

The Java Class System

Because Java narrows the use of native facilities to within the confines of a method, it does not affect the design of the program. A program is still a collection of classes and all classes still communicate with each other via their defined interface-that is, the classes' methods. Thus the callers of native methods do not know they are calling native methods. Because methods are discrete operations on the data of a specific object, they tend to be small chunks of code. This implies that native methods tend to be conceptually small, easily managed, pieces of code.

Java Still Works for You

Java will still perform a variety of duties-such as parameter checking, stack checking, synchronization, and so forth-before entering the actual native code. It greatly aids the developer in writing correct native methods. A native method is capable of creating new objects and calling Java methods, and it can even cause exceptions to be thrown. In the current implementation from Sun, an exception can be created by a native method and registered for throwing. When Java virtual machine gains control back from the native method, usually because of that method returning, the exception will then be thrown.

It's a good idea to make your native methods as small as possible and have them do a specific task. Do the work that needs to be done and pass the information back into the Java method. It's also wise to have your Java classes make the native methods private, then provide a public Java method that will call the private native method. This enables the Java method to perform error checks and other data manipulations, freeing your actual native method implementation to focus on its simple task.

How Does This Magic Work?

Much of the magic of making native methods work is provided in the next three chapters. This section provides an introduction, which neglects many of the details but should give you a good frame of reference for understanding the following chapters. If you don't really want to use native methods, but just want a basic understanding this discussion should satisfy your needs.

Sun's Implementation

Due to the lack of a well-defined interface between a Java implementation and its surrounding environment, the details of writing native methods will most likely be specific to the implementation of the Java system you are using. The next sections are based on the implementation provided by Sun on the Solaris-Sparc and Win32-Intel platforms.

Using Dynamic Linking

Sun's Java implementation interfaces to native methods by using the dynamic linking capabilities of the underlying operation system. The Java virtual machine is a complete program, which is already compiled for its respective platform. The nature of Java enables it easily to absorb a Java class and execute its behavior. However, for a compiled native method, things are not so simple. Somehow, the Java virtual machine must be taught how to call this native method. This is done by relying on the implementation of native methods to reside in a dynamic link library, which the operating system magically loads and links into the process that is running the Java virtual machine. On the Solaris platform, such a library is often called shared objects, or shared libraries, or simply dot-so's (.so's). On Win32 platforms, they are called dynamic link libraries(DLLs). This chapter uses DLL to refer to both.

Both Solaris and Win32 provide the necessary capabilities to achieve this dynamic linking. The dynamic linking facilities of both Solaris and Win32 are similar in concept, but differ in their details. This chapter does not attempt to describe the two in detail; however, if you wish to do native method programming, you should understand the mechanism used by your platform. On Solaris, you can begin by viewing the manual page on the dlopen() system call, and its relatives. On Win32, start with the help file on LoadLibrary() and its relatives. Further, you should understand the calling conventions and linking convention used by your compiler.

Sometime before a native method is invoked, the Java virtual machine must be told to find, load, and link the necessary DLLs, which contain the native method implementations. This is conveniently achieved by using the static method java.lang.System.loadLibrary( "mystuff" ). It is worth noting here that the name passed is not the actual filename of the DLL. Java maps the passed name into an expected filename, appropriate for the underlying system, of the DLL. In the call described previously, the string "mystuff" is mapped to a DLL named libmystuff.so on Solaris and mystuff.dll on Win32. If you run the Java program under a debugger, Java conveniently maps the same name "mystuff" to libmystuff_g.so and mystuff_g.dll. This enables you to supply two versions of the DLL-one with debug symbols, one without. Java magically finds the right one, dependent on whether you run under a debugger or not.

Defining the Calling Convention

In, essence, Sun defines the method its Java virtual machine will use to call external functions. In order to dynamically link and call the implementation of a native method successfully, the Java virtual machine must know several details. It must know the name of the function within the DLL (the implementation of the native method) to locate the symbol and its entry point. It also must know how to call that function (its return type, number of parameters, and types of parameters). The Java virtual machine expects the functions to be coded in C using the calling conventions appropriate for the underlying architecture (and compiler).

In simple terms, this means the actual function calls Java makes into the DLL must be known names; if you are trying to get Java to call into your existing library, unless your functions magically match the names Java expects (unlikely), you will usually have glue code, which sits between Java and your real functions. Java will call the glue functions, which in turn call in your functions. Alternatively, you can modify your functions to use the names and parameters Java expects, thus eliminating this extra call; however, in practice this is not always feasible, especially when calling existing libraries. Figure 30.2 shows the most likely scenarios of how your code will be segmented.

Figure 30.2 : Java's use of Dynamic Link Libraries.

The Sun JDK provides a tool, named javah, to help you create your native method implementation functions. The developer of native methods runs javah, passing it the name of a class. javah emits both a header file (.h) and a code file (.c) containing information about each native method and relevant type declarations. The .h file will contain the prototypes of the functions Java will call, and thus expect to find in the DLL. The .c file will contain stubs for each function. Thus, the developer needs to fill in only the details of the functions in the c file and build the DLL appropriately.

How the Virtual Machine Makes It Work

When a class is first used by Java, its class descriptor is loaded into memory. The class descriptor can be thought of as a directory for all services provided by the class-there is only one class descriptor loaded, regardless of how many instances of that class exist. Among its entries is a list of method descriptors, which contain information specific to methods, including where the code is, what parameters they take, and method modifiers.

If a method descriptor has its native modifier set, the block will include a pointer to the function that implements that native method. This function resides in some DLL but will be loaded into the Java processes address space by the operating system. At the time the class descriptor with native methods is loaded, the associated DLL does not have to be loaded, and thus the function pointer will not be set. Sometime prior to a native method being called, the associated DLL should be loaded. This is done via a call to java.system.loadLibrary(). When this call is made, Java will find and load the DLL but will still not resolve symbols; the resolution phase is delayed until the point of use. At the time of a call to a native method, Java will first check to see whether the native method implementation function has already been resolved-that is, its pointer is not null. If it has been previously resolved, the call is performed; otherwise, the resolution of the symbols is attempted. The resolution is performed by making an operating system call to see whether the symbol exists in the caller's address space. This includes the Java process and any DLLs loaded on its behalf. On Win32, this is done via a GetProcAddress() and on Solaris via a dlsym() call.

If the symbols are correctly resolved, the call is performed as if the Java virtual machine was making a standard C call to its own internal functions. If the resolution fails, the exception java.lang.UnsatisfiedLinkError will be thrown at the point of the native method call.

Summary

You should now have a basic understanding of how native methods enable a Java program to access the outside environment. Whether that consists of an operating system, a browser, or your own existing libraries, your Java code can reach them. It should now be clear that native methods do not come without some cost. You lose a lot of the benefits of the Java language. When there is no choice, however, native methods are there to be used. With the basic understanding of how native methods work you should be ready to tackle the next chapters, which provide more in-depth examples of native methods in action, as well as more tips and tricks to help you.

JUnit 4 is a completely different API from the versions that came before it and depends on new features of Java 5.0 (annotations, static import…). As you'll see, JUnit 4 is simpler, richer, and easier to use and introduces more flexible initialization and cleanup, timeouts, and parameterized test cases.

Nothing beats a bit of code for clarification. I'll use an example that I can use to illustrate different test cases throughout the article: a calculator. The sample calculator is very simple, inefficient, and even has a few bugs; it only manipulates integers and stores the result in a static variable. Substract method does not return a valid result, multiply is not implemented yet, and it looks like there is a bug on the squareRoot method: It loops infinitely. These bugs will help illustrate the efficiency of the tests in JUnit 4. You can switch this calculator on and off and you can clear the result. Here is the code:

package calc;

public class Calculator {

    private static int result;          // Static variable where the result is stored

    public void add(int n) {
        result = result + n;
    }

    public void substract(int n) {
        result = result - 1;          //Bug : should be result = result - n
    }

    public void multiply(int n) {}     //Not implemented yet

    public void divide(int n) {
        result = result / n;
    }

    public void square(int n) {
        result = n * n;
    }

    public void squareRoot(int n) {
        for (; ;) ;                    //Bug : loops indefinitely
    }

    public void clear() {               // Cleans the result
        result = 0;
    }

    public void switchOn() {          // Swith on the screen, display "hello", beep
        result = 0;                    // and do other things that calculator do nowadays
    }

    public void switchOff() { }	     // Display "bye bye", beep, switch off the screen

    public int getResult() {
        return result;
    }
}

package junit3; 

import calc.Calculator; 
import junit.framework.TestCase; 




public class CalculatorTest extends TestCase {

  private static Calculator calculator = 
             new Calculator();

  @Override
protected void setUp() {
      calculator.clear();
  }


  public void testAdd() {
    calculator.add(1); 
    calculator.add(1); 
    assertEquals(calculator.getResult(), 2); 
  }


  public void testSubtract() {
    calculator.add(10); 
    calculator.subtract(2); 
    assertEquals(calculator.getResult(), 8); 
  }


  public void testDivide() {
    calculator.add(8); 
    calculator.divide(2); 
assert calculator.getResult() == 5;
  }

  public void testDivideByZero()  {
    try {
      calculator.divide(0); 
fail();
    } catch (ArithmeticException e) {
    }
  }

  public void notReadyYetTestMultiply() {
    calculator.add(10); 
    calculator.multiply(10); 
    assertEquals(calculator.getResult(), 100); 
    }
}

package junit4; 

import calc.Calculator; 
import org.junit.Before; 
import org.junit.Ignore; 
import org.junit.Test; 
import static org.junit.Assert.*;

public class CalculatorTest {

  private static Calculator calculator = 
             new Calculator();

@Before
public void clearCalculator() {
    calculator.clear();
  }

@Test
  public void add() {
    calculator.add(1); 
    calculator.add(1); 
    assertEquals(calculator.getResult(), 2); 
  }

@Test
  public void subtract() {
    calculator.add(10); 
    calculator.subtract(2); 
    assertEquals(calculator.getResult(), 8); 
  }

@Test
  public void divide() {
    calculator.add(8); 
    calculator.divide(2); 
    assert calculator.getResult() == 5; 
  }

@Test(expected = ArithmeticException.class)
  public void divideByZero() {
    calculator.divide(0); 
  }


@Ignore("not ready yet")
  @Test
  public void multiply() {
    calculator.add(10); 
    calculator.multiply(10); 
    assertEquals(calculator.getResult(), 100); 
  }
}

public static void assertEquals(String message, Object[] expecteds, Object[] actuals);
public static void assertEquals(Object[] expecteds, Object[] actuals);

java.lang.Exception: Method xxx should have no parameters
java.lang.Exception: Method xxx should be void

java -ea junit.textui.TestRunner junit3.CalculatorTest

..F.E.

There was 1 error:
1) testDivide(junit3.CalculatorTest)java.lang.AssertionError
        at junit3.CalculatorTest.testDivide(CalculatorTest.java:33)

There was 1 failure:
1) testSubtract(junit3.CalculatorTest)junit.framework.AssertionFailedError: expected:<9> but was:<8>
        at junit3.CalculatorTest.testSubtract(CalculatorTest.java:27)

FAILURES!!!
Tests run: 4,  Failures: 1,  Errors: 1

java –ea org.junit.runner.JUnitCore junit3.CalculatorTest
JUnit version 4.1

..E.E.

There were 2 failures:
1) testSubtract(junit3.CalculatorTest)
junit.framework.AssertionFailedError: expected:<9> but was:<8>
        at junit.framework.Assert.fail(Assert.java:47)
2) testDivide(junit3.CalculatorTest)
java.lang.AssertionError
        at junit3.CalculatorTest.testDivide(CalculatorTest.java:33)

FAILURES!!!
Tests run: 4,  Failures: 2

java –ea org.junit.runner.JUnitCore junit4.CalculatorTest
JUnit version 4.1

...E.EI

There were 2 failures:
1) subtract(junit4.CalculatorTest)
java.lang.AssertionError: expected:<9> but was:<8>
        at org.junit.Assert.fail(Assert.java:69)
2) divide(junit4.CalculatorTest)
java.lang.AssertionError
        at junit4.CalculatorTest.divide(CalculatorTest.java:40)

FAILURES!!!
Tests run: 4,  Failures: 2

Start test system                //@BeforeClass of parent
  Switch on calculator           //@BeforeClass of child

    Initialize test system       //First test
    Clear calculator

    Initialize test system       //Second test
    Clear calculator
    Clean test system

    Initialize test system       //Third test
    Clear calculator
    Clean test system

    Initialize test system       //Forth test
    Clear calculator
    Clean test system

  Switch off calculator          //@AfterClass of child
Stop test system                 //@AfterClass of parent

There was 1 failure:
1) squareRoot(junit4.AdvancedTest)
java.lang.Exception: test timed out after 1000 milliseconds
        at org.junit.internal.runners.TestMethodRunner.runWithTimeout(TestMethodRunner.java:68)
        at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:43)

FAILURES!!!
Tests run: 4,  Failures: 1

java org.junit.runner.JUnitCore junit4.SquareTest
JUnit version 4.1

.......E

There was 1 failure:
1) square[6](junit4.SquareTest)
java.lang.AssertionError: expected:<48> but was:<49>
        at org.junit.Assert.fail(Assert.java:69)

FAILURES!!!
Tests run: 7,  Failures: 1

package junit4;

import org.junit.runner.RunWith;
import org.junit.runners.Suite;

@RunWith(Suite.class)
@Suite.SuiteClasses({
        CalculatorTest.class,
        SquareTest.class
        })
public class AllCalculatorTests {
}

java -ea org.junit.runner.JUnitCore junit4.AllCalculatorTests
JUnit version 4.1

...E.EI.......E

There were 3 failures:
1) subtract(junit4.CalculatorTest)
java.lang.AssertionError: expected:<9> but was:<8>
        at org.junit.Assert.fail(Assert.java:69)
2) divide(junit4.CalculatorTest)
java.lang.AssertionError
        at junit4.CalculatorTest.divide(CalculatorTest.java:40)
3) square[6](junit4.SquareTest)
java.lang.AssertionError: expected:<48> but was:<49>
        at org.junit.Assert.fail(Assert.java:69)

FAILURES!!!
Tests run: 11,  Failures: 3

import org.junit.internal.runners.TestClassRunner;
import org.junit.runner.RunWith;

@RunWith(TestClassRunner.class)
public class CalculatorTest {
...
}

Tools Integration (or Lack Thereof) As I'm writing this article, JUnit 4 integration in IDEs is not yet perfect. In fact if you try to run the test classes we’ve just seen, they will not work in any IDE because they are not recognized as being test classes. For forward compatibility JUnit 4 comes with an adapter (junit.framework.JUnit4TestAdapter) that you have to use in a suite() method. Here is the code you have to add in every class to make them understandable by IDEs, Ant, and JUnit 3.8 text runner: public static junit.framework.Test suite() { return new JUnit4TestAdapter(CalculatorTest.class); } Intellij IDEA IDEA 5 does not integrate JUnit 4. We will have to wait for IDEA 6. In the meantime I've used the early access version (Demetra build 5321). The parameterized test case didn't work. Figure 1 shows the CalculatorTest executing (the ignored test is represented with a different icon). Figure 1. IDEA Demetra is only running CalculatorTest.   Figure 2. Eclipse 3.2RC7 is running the suite class AllCalculatorTests. Eclipse I’ve used the version 3.2 RC7 of Eclipse. It is not a stable version but the integration with JUnit 4 is much better than with IDEA. Figure 2 shows what you get when running the AllCalculatorTests class. As you can see, the parameterized test case (SquareTest) is represented as seven individual tests. Ant Integration The junit task currently only supports JUnit 3.8 style tests, meaning you also have to wrap your JUnit 4 tests in a JUnit4TestAdapter in order to run them in Ant. The <junit> task is used in exactly the same way as in JUnit 3.8: <!-- Test --> <target name="test" depends="compile"> <junit fork="yes" haltonfailure="yes"> <test name=" junit4.AllCalculatorTests"/> <formatter type="plain" usefile="false"/> <classpath refid="classpath"/> </junit> </target> JUnit: Losing Market or Coming Back Strong? For a long time JUnit was the defacto unit testing framework. But lately not much has happened to this framework: no major release, no notable new features. This is possibly the reason why other frameworks, such as Test-NG have started taking over. With this new version, JUnit is back on track. It has new APIs and now uses annotations, making it easier to develop test cases. In fact, the JUnit developers have started to think of new, future annotations. For example, you could add a @Prerequisite annotation for a test case that depends on prerequisites (e.g. you need to be online to execute this test); or add a @Repeat annotation that would specify the number of repetitions along with a timeout (e.g. repeat a test five times to make sure there is a real timeout problem); or even add a platform parameter to the @Ignore annotation (e.g. @Ignore(platform=macos), which would ignore a test only if you run on a MacOS platform). As you can see, JUnit is still alive with a promising future. Antonio Goncalves is a senior architect specialized in Java/J2EE. Former BEA consultant he now helps insurance, finance and telecommunication clients set up their architectures. He also teaches J2EE at CNAM University in Paris.

J Unit Cookbook

Kent Beck, Erich Gamma

Simple Test Case

The simplest way is as an expression in a debugger. You can change debug expressions without recompiling, and you can wait to decide what to write until you have seen the running objects. You can also write test expressions as statements which print to the standard output stream. Both styles of tests are limited because they require human judgment to analyze their results. Also, they don't compose nicely- you can only execute one debug expression at a time and a program with too many print statements causes the dreaded "Scroll Blindness".

JUnit tests do not require human judgment to interpret, and it is easy to run many of them at the same time. When you need to test something, here is what you do:

1. Annotate a method with @org.junit.Test
2. When you want to check a value, import org.junit.Assert.* statically, call assertTrue() and pass a boolean that is true if the test succeeds

@Test public void simpleAdd() {
    Money m12CHF= new Money(12, "CHF"); 
    Money m14CHF= new Money(14, "CHF"); 
    Money expected= new Money(26, "CHF"); 
    Money result= m12CHF.add(m14CHF); 
    assertTrue(expected.equals(result));
}

Fixture

Tests need to run against the background of a known set of objects. This set of objects is called a test fixture. When you are writing tests you will often find that you spend more time writing the code to set up the fixture than you do in actually testing values.

To some extent, you can make writing the fixture code easier by paying careful attention to the constructors you write. However, a much bigger savings comes from sharing fixture code. Often, you will be able to use the same fixture for several different tests. Each case will send slightly different messages or parameters to the fixture and will check for different results.

When you have a common fixture, here is what you do:

1. Add a field for each part of the fixture
2. Annotate a method with @org.junit.Before and initialize the variables in that method
3. Annotate a method with @org.junit.After to release any permanent resources you allocated in setUp

public class MoneyTest { 
    private Money f12CHF; 
    private Money f14CHF; 
    private Money f28USD; 
    
    @Before public void setUp() { 
        f12CHF= new Money(12, "CHF"); 
        f14CHF= new Money(14, "CHF"); 
        f28USD= new Money(28, "USD"); 
    }
}

Running Tests

Once you have tests, you'll want to run them. JUnit provides tools to define the suite to be run and to display its results. To run tests and see the results on the console, run:

org.junit.JUnitCore.runClasses(TestClass1.class, ...); 

public static junit.framework.Test suite() { 
    return new JUnit4TestAdapter(Example.class); 
}

Expected Exceptions

Verifying that code completes normally is only part of programming. Making sure the code behaves as expected in exceptional situations is part of the craft of programming too. For example:

new ArrayList<Object>().get(0); 

@Test(expected= IndexOutOfBoundsException.class) public void empty() { 
    new ArrayList<Object>().get(0); 
}

JUnit 由 Kent Beck 和 Erich Gamma 开发，几乎毫无疑问是迄今所开发的最重要的第三方 Java 库。正如 Martin Fowler 所说，“在软件开发领域，从来就没有如此少的代码起到了如此重要的作用”。JUnit 引导并促进了测试的盛行。由于 JUnit，Java 代码变得更健壮，更可靠，bug 也比以前更少。JUnit（它本身的灵感来自 Smalltalk 的 SUnit）衍生了许多 xUnit 工具，将单元测试的优势应用于各种语言。nUnit (.NET)、pyUnit (Python)、CppUnit (C++)、dUnit (Delphi) 以及其他工具，影响了各种平台和语言上的程序员的测试工作。

然而，JUnit 仅仅是一个工具而已。真正的优势来自于 JUnit 所采用的思想和技术，而不是框架本身。单元测试、测试先行的编程和测试驱动的开发并非都要在 JUnit 中实现，任何比较 GUI 的编程都必须用 Swing 来完成。JUnit 本身的最后一次更新差不多是三年以前了。尽管它被证明比大多数框架更健壮、更持久，但是也发现了 bug；而更重要的是，Java 不断在发展。Java 语言现在支持泛型、枚举、可变长度参数列表和注释，这些特性为可重用的框架设计带来了新的可能。

JUnit 的停滞不前并没有被那些想要废弃它的程序员所打败。挑战者包括 Bill Venners 的 Artima SuiteRunner 以及 Cedric Beust 的 TestNG 等。这些库有一些可圈可点的特性，但是都没有达到 JUnit 的知名度和市场占有份额。它们都没有在诸如 Ant、Maven 或 Eclipse 之类的产品中具有广泛的开箱即用支持。所以 Beck 和 Gamma 着手开发了一个新版本的 JUnit，它利用 Java 5 的新特性（尤其是注释）的优势，使得单元测试比起用最初的 JUnit 来说更加简单。用 Beck 的话来说，“JUnit 4 的主题是通过进一步简化 JUnit，鼓励更多的开发人员编写更多的测试。”JUnit 4 尽管保持了与现有 JUnit 3.8 测试套件的向后兼容，但是它仍然承诺是自 JUnit 1.0 以来 Java 单元测试方面最重大的改进。

注意：该框架的改进是相当前沿的。尽管 JUnit 4 的大轮廓很清晰，但是其细节仍然可以改变。这意味着本文是对 JUnit 4 抢先看，而不是它的最终效果。

测试方法

以前所有版本的 JUnit 都使用命名约定和反射来定位测试。例如，下面的代码测试 1+1 等于 2：

import junit.framework.TestCase;
public class AdditionTest extends TestCase {
  private int x = 1;
  private int y = 1;

  public void testAddition() {
    int z = x + y;
    assertEquals(2, z);
  }
}

而在 JUnit 4 中，测试是由 @Test 注释来识别的，如下所示：

import org.junit.Test;
import junit.framework.TestCase;
public class AdditionTest extends TestCase {
  private int x = 1;
  private int y = 1;

  @Test public void testAddition() {
    int z = x + y;
    assertEquals(2, z);
  }
}

使用注释的优点是不再需要将所有的方法命名为 testFoo()、testBar()，等等。例如，下面的方法也可以工作：

import org.junit.Test;
import junit.framework.TestCase;
public class AdditionTest extends TestCase {
  private int x = 1;
  private int y = 1;

  @Test public void additionTest() {
    int z = x + y;
    assertEquals(2, z);
  }
}

下面这个方法也同样能够工作：

import org.junit.Test;
import junit.framework.TestCase;
public class AdditionTest extends TestCase {
  private int x = 1;
  private int y = 1;

  @Test public void addition() {
    int z = x + y;
    assertEquals(2, z);
  }
}

这允许您遵循最适合您的应用程序的命名约定。例如，我介绍的一些例子采用的约定是，测试类对其测试方法使用与被测试的类相同的名称。例如，List.contains() 由 ListTest.contains() 测试，List.add() 由 ListTest.addAll() 测试，等等。

TestCase 类仍然可以工作，但是您不再需要扩展它了。只要您用 @Test 来注释测试方法，就可以将测试方法放到任何类中。但是您需要导入 junit.Assert 类以访问各种 assert 方法，如下所示：

import org.junit.Assert;
public class AdditionTest {
  private int x = 1;
  private int y = 1;

  @Test public void addition() {
    int z = x + y;
    Assert.assertEquals(2, z);
  }
}

您也可以使用 JDK 5 中新特性（static import），使得与以前版本一样简单：

import static org.junit.Assert.assertEquals;
public class AdditionTest {
  private int x = 1;
  private int y = 1;

  @Test public void addition() {
    int z = x + y;
    assertEquals(2, z);
  }
}

这种方法使得测试受保护的方法非常容易，因为测试案例类现在可以扩展包含受保护方法的类了。

回页首

SetUp 和 TearDown

JUnit 3 测试运行程序（test runner）会在运行每个测试之前自动调用 setUp() 方法。该方法一般会初始化字段，打开日志记录，重置环境变量，等等。例如，下面是摘自 XOM 的 XSLTransformTest 中的 setUp() 方法：

protected void setUp() {

    System.setErr(new PrintStream(new ByteArrayOutputStream()));

    inputDir = new File("data");
    inputDir = new File(inputDir, "xslt");
    inputDir = new File(inputDir, "input");

}

在 JUnit 4 中，您仍然可以在每个测试方法运行之前初始化字段和配置环境。然而，完成这些操作的方法不再需要叫做 setUp()，只要用 @Before 注释来指示即可，如下所示：

@Before protected void initialize() {

    System.setErr(new PrintStream(new ByteArrayOutputStream()));

    inputDir = new File("data");
    inputDir = new File(inputDir, "xslt");
    inputDir = new File(inputDir, "input");

}

甚至可以用 @Before 来注释多个方法，这些方法都在每个测试之前运行：

@Before protected void findTestDataDirectory() {
    inputDir = new File("data");
    inputDir = new File(inputDir, "xslt");
    inputDir = new File(inputDir, "input");
}

 @Before protected void redirectStderr() {
    System.setErr(new PrintStream(new ByteArrayOutputStream()));
}

清除方法与此类似。在 JUnit 3 中，您使用 tearDown() 方法，该方法类似于我在 XOM 中为消耗大量内存的测试所使用的方法：

protected void tearDown() {
  doc = null;
  System.gc();   
} 

对于 JUnit 4，我可以给它取一个更自然的名称，并用 @After 注释它：

@After protected void disposeDocument() {
  doc = null;
  System.gc();   
} 

与 @Before 一样，也可以用 @After 来注释多个清除方法，这些方法都在每个测试之后运行。

最后，您不再需要在超类中显式调用初始化和清除方法，只要它们不被覆盖即可，测试运行程序将根据需要自动为您调用这些方法。超类中的 @Before 方法在子类中的 @Before 方法之前被调用（这反映了构造函数调用的顺序）。@After 方法以反方向运行：子类中的方法在超类中的方法之前被调用。否则，多个 @Before 或 @After 方法的相对顺序就得不到保证。

套件范围的初始化

JUnit 4 也引入了一个 JUnit 3 中没有的新特性：类范围的 setUp() 和 tearDown() 方法。任何用 @BeforeClass 注释的方法都将在该类中的测试方法运行之前刚好运行一次，而任何用 @AfterClass 注释的方法都将在该类中的所有测试都运行之后刚好运行一次。

例 如，假设类中的每个测试都使用一个数据库连接、一个网络连接、一个非常大的数据结构，或者还有一些对于初始化和事情安排来说比较昂贵的其他资源。不要在每 个测试之前都重新创建它，您可以创建它一次，并还原它一次。该方法将使得有些测试案例运行起来快得多。例如，当我测试调用第三方库的代码中的错误处理时， 我通常喜欢在测试开始之前重定向 System.err，以便输出不被预期的错误消息打乱。然后我在测试结束后还原它，如下所示：

// This class tests a lot of error conditions, which
// Xalan annoyingly logs to System.err. This hides System.err 
// before each test and restores it after each test.
private PrintStream systemErr;

@BeforeClass protected void redirectStderr() {
    systemErr = System.err; // Hold on to the original value
    System.setErr(new PrintStream(new ByteArrayOutputStream()));
}

@AfterClass protected void tearDown() {
    // restore the original value
    System.setErr(systemErr);
}

没有必要在每个测试之前和之后都这样做。但是一定要小心对待这个特性。它有可能会违反测试的独立性，并引入非预期的混乱。如果一个测试在某种程度上改变了 @BeforeClass 所初始化的一个对象，那么它有可能会影响其他测试的结果。它有可能在测试套件中引入顺序依赖，并隐藏 bug。与任何优化一样，只在剖析和基准测试证明您具有实际的问题之后才实现这一点。这就是说，我看到了不止一个测试套件运行时间如此之长，以至不能像它 所需要的那样经常运行，尤其是那些需要建立很多网络和数据库连接的测试。（例如，LimeWire 测试套件运行时间超过两小时。）要加快这些测试套件，以便程序员可以更加经常地运行它们，您可以做的就是减少 bug。

回页首

测试异常

异常测试是 JUnit 4 中的最大改进。旧式的异常测试是在抛出异常的代码中放入 try 块，然后在 try 块的末尾加入一个 fail() 语句。例如，该方法测试被零除抛出一个 ArithmeticException：

public void testDivisionByZero() {

    try {
        int n = 2 / 0;
        fail("Divided by zero!");
    }
    catch (ArithmeticException success) {
        assertNotNull(success.getMessage());
    }

}

该方法不仅难看，而且试图挑战代码覆盖工具，因为不管测试是通过还是失败，总有一些代码不被执行。在 JUnit 4 中，您现在可以编写抛出异常的代码，并使用注释来声明该异常是预期的：

@Test(expected=ArithmeticException.class) 
  public void divideByZero() {
    int n = 2 / 0;
}

如果该异常没有抛出（或者抛出了一个不同的异常），那么测试就将失败。但是如果您想要测试异常的详细消息或其他属性，则仍然需要使用旧式的 try-catch 样式。

回页首

被忽略的测试

也 许您有一个测试运行的时间非常地长。不是说这个测试应该运行得更快，而是说它所做的工作从根本上比较复杂或缓慢。需要访问远程网络服务器的测试通常都属于 这一类。如果您不在做可能会中断该类测试的事情，那么您可能想要跳过运行时间长的测试方法，以缩短编译-测试-调试周期。或者也许是一个因为超出您的控制 范围的原因而失败的测试。例如，W3C XInclude 测试套件测试 Java 还不支持的一些 Unicode 编码的自动识别。不必老是被迫盯住那些红色波浪线，这类测试可以被注释为 @Ignore，如下所示：

// Java doesn't yet support 
// the UTF-32BE and UTF32LE encodings
    @Ignore public void testUTF32BE() 
      throws ParsingException, IOException, XIncludeException {

        File input = new File(
          "data/xinclude/input/UTF32BE.xml"
        );
        Document doc = builder.build(input);
        Document result = XIncluder.resolve(doc);
        Document expectedResult = builder.build(
          new File(outputDir, "UTF32BE.xml")
        );
        assertEquals(expectedResult, result);

    }

测试运行程序将不运行这些测试，但是它会指出这些测试被跳过了。例如，当使用文本界面时，会输出一个“I”（代表 ignore），而不是为通过的测试输出所经历的时间，也不是为失败的测试输出“E”：

$ java -classpath .:junit.jar org.junit.runner.JUnitCore 
  nu.xom.tests.XIncludeTest
JUnit version 4.0rc1
.....I..
Time: 1.149
OK (7 tests)

但是一定要小心。最初编写这些测试可能有一定的原因。如果永远忽略这些测试，那么它们期望测试的代码可能会中断，并且这样的中断可能不能被检测到。忽略测试只是一个权宜之计，不是任何问题的真正解决方案。

回页首

时间测试

测 试性能是单元测试最为痛苦的方面之一。JUnit 4 没有完全解决这个问题，但是它对这个问题有所帮助。测试可以用一个超时参数来注释。如果测试运行的时间超过指定的毫秒数，则测试失败。例如，如果测试花费 超过半秒时间去查找以前设置的一个文档中的所有元素，那么该测试失败：

@Test(timeout=500) public void retrieveAllElementsInDocument() {
    doc.query("//*");
} 

除 了简单的基准测试之外，时间测试也对网络测试很有用。在一个测试试图连接到的远程主机或数据库宕机或变慢时，您可以忽略该测试，以便不阻塞所有其他的测 试。好的测试套件执行得足够快，以至程序员可以在每个测试发生重大变化之后运行这些测试，有可能一天运行几十次。设置一个超时使得这一点更加可行。例如， 如果解析 http://www.ibiblio.org/xml 花费了超过 2 秒，那么下面的测试就会超时：

@Test(timeout=2000) 
  public void remoteBaseRelativeResolutionWithDirectory()
   throws IOException, ParsingException {
      builder.build("http://www.ibiblio.org/xml");
  } 

回页首

新的断言

JUnit 4 为比较数组添加了两个 assert() 方法：

public static void assertEquals(Object[] expected, Object[] actual)
public static void assertEquals(String message, Object[] expected, 
Object[] actual)

这两个方法以最直接的方式比较数组：如果数组长度相同，且每个对应的元素相同，则两个数组相等，否则不相等。数组为空的情况也作了考虑。

回页首

需要补充的地方

JUnit 4 基本上是一个新框架，而不是旧框架的升级版本。JUnit 3 开发人员可能会找到一些原来没有的特性。

最明显的删节就是 GUI 测试运行程序。如果您想在测试通过时看到赏心悦目的绿色波浪线，或者在测试失败时看到令人焦虑的红色波浪线，那么您需要一个具有集成 JUnit 支持的 IDE，比如 Eclipse。不管是 Swing 还是 AWT 测试运行程序都不会被升级或捆绑到 JUnit 4 中。

下一个惊喜是，失败（assert 方法检测到的预期的错误）与错误（异常指出的非预期的错误）之间不再有任何差别。尽管 JUnit 3 测试运行程序仍然可以区别这些情况，而 JUnit 4 运行程序将不再能够区分。

最后，JUnit 4 没有 suite() 方法，这些方法用于从多个测试类构建一个测试套件。相反，可变长参数列表用于允许将不确定数量的测试传递给测试运行程序。

我对消除了 GUI 测试运行程序并不感到太高兴，但是其他更改似乎有可能增加 JUnit 的简单性。只要考虑有多少文档和 FAQ 当前专门用于解释这几点，然后考虑对于 JUnit 4，您不再需要解释这几点了。

回页首

编译和运行 JUnit 4

当前，还没有 JUnit 4 的库版本。如果您想要体验新的版本，那么您需要从 SourceForge 上的 CVS 知识库获取它。分支（branch）是“Version4”（参见 参考资料）。注意，很多的文档没有升级，仍然是指以旧式的 3.x 方式做事。Java 5 对于编译 JUnit 4 是必需的，因为 JUnit 4 大量用到注释、泛型以及 Java 5 语言级的其他特性。

自 JUnit 3 以来，从命令行运行测试的语法发生了一点变化。您现在使用 org.junit.runner.JUnitCore 类：

$ java -classpath .:junit.jar org.junit.runner.JUnitCore 
  TestA TestB TestC...
JUnit version 4.0rc1
Time: 0.003
OK (0 tests)

兼容性

Beck 和 Gamma 努力维持向前和向后兼容。JUnit 4 测试运行程序可以运行 JUnit 3 测试，不用做任何更改。只要将您想要运行的每个测试的全限定类名传递给测试运行程序，就像针对 JUnit 4 测试一样。运行程序足够智能，可以分辨出哪个测试类依赖于哪个版本的 JUnit，并适当地调用它。

向后兼容要困难一些，但是也可以在 JUnit 3 测试运行程序中运行 JUnit 4 测试。这一点很重要，所以诸如 Eclipse 之类具有集成 JUnit 支持的工具可以处理 JUnit 4，而不需要更新。为了使 JUnit 4 测试可以运行在 JUnit 3 环境中，可以将它们包装在 JUnit4TestAdapter 中。将下面的方法添加到您的 JUnit 4 测试类中应该就足够了：

public static junit.framework.Test suite() {
  return new JUnit4TestAdapter(AssertionTest.class);    
}

但是由于 Java 比较多变，所以 JUnit 4 一点都不向后兼容。JUnit 4 完全依赖于 Java 5 特性。对于 Java 1.4 或更早版本，它将不会编译或运行。

回页首

前景

JUnit 4 远没有结束。很多重要的方面没有提及，包括大部分的文档。我不推荐现在就将您的测试套件转换成注释和 JUnit 4。即使如此，开发仍在快速进行，并且 JUnit 4 前景非常看好。尽管 Java 2 程序员在可预见的未来仍然需要使用 JUnit 3.8，但是那些已经转移到 Java 5 的程序员则应该很快考虑使他们的测试套件适合于这个新的框架，以便匹配。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
  
  
• Pragmatic Unit Testing in Java with JUnit （Andy Hunt 和 Dave Thomas，Pragmatic Programmers，2003 年）：非常好地介绍了单元测试。
  
  
• JUnit Recipes: Practical Methods for Programmer Testing （J. B. Rainsberger，Manning，2004 年）：一本最广泛地引用和参考了 JUnit 的书籍。
  
  
• TestNG：Cedric Beust 的框架，基于现在用于 JUnit 4 中的测试样式，最先使用了注释。
  
  
• “TestNG 使 Java 单元测试轻而易举”（Filippo Diotalevi，developerWorks，2005 年 1 月）：介绍了 TestNG。
  
  
• “利用 Ant 和 JUnit 进行增量开发”（Malcolm Davis，developerWorks，2000 年 11 月）：探讨了单元测试的优势，具体使用了 Ant 和 JUnit，并有示例代码。
  
  
• “揭开极端编程的神秘面纱: 测试驱动的编程”（Roy Miller，developerWorks，2003 年 4 月）：找出测试驱动的编程可以如何提高程序员的生产效率和质量，并学习编写测试的机制。
  
  
• “Keeping critters out of your code”（David Carew 等人，developerWorks，2003 年 6 月）：学习可以如何将 JUnit 与 WebSphere Application Developer 结合起来使用。
  
  
• “用 Cobertura 测量测试覆盖率”（Elliotte Rusty Harold，developerWorks，2005 年 5 月）：学习用这个方便的开放源码工具来识别未测试的代码和查找 bug。
  
  

• developerWorks blogs：加入 developerWorks 社区。

关于作者

		Elliotte Rusty Harold 出生在新奥尔良，现在，他还定期回老家喝一碗美味的秋葵汤。不过目前他与妻子 Beth 定居在纽约临近布鲁克林的 Prospect Heights，与他们住在一起的还有猫咪 Charm（取自夸克）和 Marjorie（按照他岳母的名字）。他是 Polytechnic 大学计算机科学的副教授，讲授 Java 技术和面向对象编程。他的 Cafe au Lait 网站是 Internet 上最受欢迎的独立 Java 站点之一，姊妹站点 Cafe con Leche 是最受欢迎的 XML 站点之一。他的著作包括 Effective XML、Processing XML with Java、Java Network Programming 和 The XML 1.1 Bible。他目前在研究处理 XML 的 XOM API、Jaxen XPath 引擎和 Jester 测试覆盖工具。

For the purpose of this article, I will call JUnit 3.8.1 and its predecessors as the old JUnit and JUnit 4.0 as the new JUnit.

Table of contents:

This guide contains the following sections:

·         Old JUnit revisited

·         Cut the chase to JUnit 4.0

·         Run the tests

·         Set up and tear down

·         One-time set up and tear down

·         Expecting exceptions

·         Other Annotations

o        Ignoring a test

o        Timing out a test

·         Summary

Old JUnit revisited

Using the old JUnit, let us write a test, which verifies the availability of a book in the library.

To summarize the steps:

·         We extend from junit.framework.TestCase.

·         We name the test methods with a prefix of ‘test’.

·         We validate conditions using one of the several assert methods.

Cut the chase to JUnit 4.0

Let us write the same test using JUnit 4.0.

When I upgrade to a new version I look for tasks, I do not have to do anymore. Here is the same code with notes telling us what not to do anymore.

To summarize:

·         We do not extend from junit.framework.TestCase.

·         We do not prefix the test method with ‘test’.

Next, I look for new tasks I must always do. The diagram below summarizes what we must do according to the new JUnit standards:

To summarize:

·         Use a normal class and not extend from junit.framework.TestCase.

·         Use the Test annotation to mark a method as a test method. To use the Test annotation, we need to import org.junit.Test

·         Use one of the assert methods. There is no difference between the old assert methods and the new assert methods. An easy way to use the assert method is to do a static import as shown by point 2 in the code above.

·         Run the test using JUnit4TestAdapter. If you want to learn more about JUnit4TestAdapter, keep reading ahead.

Run the tests

Unfortunately, our favorite development environments are still unaware of JUnit 4. JUnit4Adapter enables compatibility with the old runners so that the new JUnit 4 tests can be run with the old runners. The suite method in the diagram above illustrates the use of JUnit4Adapter.

Alternatively, you can use the JUnitCore class in the org.junit.runner package. JUnit 4 runner can also run tests written using the old JUnit. To run the tests using the JUnitCore class via the command line, type:

java org.junit.runner.JUnitCore LibraryTest

Set up and tear down

The new JUnit provides two new annotations for set up and tear down:

·         @Before: Method annotated with @Before executes before every test.

·         @After: Method annotated with @After executes after every test.

Here is the code that demonstrates the use of @Before and @After:

Two features of @Before and @After annotations that are helpful to learn:

·         You can have any number of @Before and @After as you need.

·         It is possible to inherit the @Before and @After methods. New JUnit executes @Before methods in superclass before the inherited @Before methods. @After methods in subclasses are executed before the inherited @After methods.

One-time set up and tear down

The new JUnit4 provides @BeforeClass and @AfterClass annotations for one-time set up and tear down. This is similar to the TestSetup class in the old junit.extensions package, which ran setup code once before all the tests and cleanup code once after all the tests.

Here is the code that demonstrates @BeforeClass and @AfterClass:

Unlike @Before and @After annotations, only one set of @BeforeClass and @AfterClass annotations are allowed.

Expecting exceptions

The new JUnit makes checking for exceptions very easy. The @Test annotation takes a parameter, which declares the type of Exception that should be thrown. The code below demonstrates this:

In the code above, bookNotAvailableInLibrary is a test, which passes only if BookNotAvailableException is thrown. The test fails if no exception is thrown. Test also fails if a different exception is thrown.

Other Annotations

Ignoring a test

The @Ignore annotation tells the runner to ignore the test and report that it was not run. You can pass in a string as a parameter to @Ignore annotation that explains why the test was ignored. E.g. The new JUnit will not run a test method annotated with @Ignore(“Database is down”) but will only report it. The version of JUnit4Adapter, I used, did not work with @Ignore annotation. Kent Beck has informed me that the next version of JUnitAdapter will fix this problem.

Timing out a test

You can pass in a timeout parameter to the test annotation to specify the timeout period in milliseconds. If the test takes more, it fails. E.g. A method annotated with @Test (timeout=10) fails if it takes more than 10 milliseconds.

Finally, I would like to thank Kent Beck for taking the time to demonstrate and teach the new JUnit to me.

Summary

To summarize the new JUnit style:

1. It Requires JDK 5 to run.
2. Test classes do not have to extend from junit.framework.TestCase.
3. Test methods do not have to be prefixed with ‘test’.
4. There is no difference between the old assert methods and the new assert methods.
5. Use @Test annotations to mark a method as a test case.
6. @Before and @After annotations take care of set up and tear down.
7. @BeforeClass and @AfterClass annotations take care of one time set up and one time tear down.
8. @Test annotations can take a parameter for timeout. Test fails if the test takes more time to execute.
9. @Test annotations can take a parameter that declares the type of exception to be thrown.
10. JUnit4Adapter enables running the new JUnit4 tests using the old JUnit runners.
11. Old JUnit tests can be run in the new JUnit4 runner.

原文链接：http://www.blogjava.net/easyjf/archive/2006/11/19/82072.aspx

这篇文章算是一个翻译了。分成两部分，集合了两篇 JUnit.org 上的推荐文章，这里是原文的地址：

http://www.instrumentalservices.com/index.php?option=com_content&task=view&id=45&Itemid=52

http://www.devx.com/Java/Article/31983

JUnit 我就不多做介绍了， Kent Beck 和 Erich Gamma 的作品。这里主要讲一下在 JUnit 4.0 和 4.1 版本中的一些改进和新的用法。

要很好的使用 JUnit 4.x ，必须要 Java SE 5.0 ，因为这个版本最大的变化就是加入了大量的 Annotation 的使用。

来通过一个例子看下，首先是一个老版本的测试案例：

图1 Java数据库访问机制

　　JDBC作为一种数据库访问技术，具有简单易用的优点。但使用这种模式进行Web应用

　 　程序开发，存在很多问题：首先，每一次Web请求都要建立一次数据库连接。建立连接是一个费时的活动，每次都得花费0.05s～1s的时间，而且系统还 要分配内存资源。这个时间对于一次或几次数据库操作，或许感觉不出系统有多大的开销。可是对于现在的Web应用，尤其是大型电子商务网站，同时有几百人甚 至几千人在线是很正常的事。在这种情况下，频繁的进行数据库连接操作势必占用很多的系统资源，网站的响应速度必定下降，严重的甚至会造成服务器的崩溃。不 是危言耸听，这就是制约某些电子商务网站发展的技术瓶颈问题。其次，对于每一次数据库连接，使用完后都得断开。否则，如果程序出现异常而未能关闭，将会导 致数据库系统中的内存泄漏，最终将不得不重启数据库。还有，这种开发不能控制被创建的连接对象数，系统资源会被毫无顾及的分配出去，如连接过多，也可能导 致内存泄漏，服务器崩溃。

图2 连接池的基本工作原理

1.在login_do.jsp登录成功的前面加上
session.setAttribute("user",model);
model里面放的是用户名和密码。
user是供后面要用到的，也可以说是指针，或键，model是值

2.单独写一个sessionCheck.jsp文件用来验证session
<%
Object obj = session.getAttribute("user");
if(obj==null){
out.print("你没有登录");
response.sendRedirect("../login.jsp");
}else{
UserModel model=(UserModel)obj;
}
%>
=-----------------------------==
我来逐行解释
第一行是设置一个键，这个键跟它的值是成对存在的。
其实就是通过这个键，来操作他的值。
如果键为空，就是值为空。
那么您没登录，因为登录过后，里面一定会有帐户和密码
否则。。。。请离开
如果不为空，把键强制转化成值

原文链接：http://hi.baidu.com/dxtao/blog/item/610bc6950674f54bd1135e14.html

Tomcat5.5.17安装admin管理插件