In the line
for (int i = 0; i < ints.size; i++) { s += ints[i]; }
the word size should be length. The original fails compilation.

The line

ints.add(new Integer(1));

should be changed to

ints.add(Integer.valueOf(1));

That's what Sun's compiler generates (and probably all others). Integer.valueOf() caches small values. The following sentence, which mentions caching, should be changed to explain the use of valueOf().

Note from the Author or Editor:
Fixed.

The line

List<Integer> ints = Lists.<Integer>toList();

should be changed to

List<Integer> ints = Lists.toList();

The following paragraph explains why adding "<Integer>" appears to be necessary:

"[W]ithout the type parameter there is too little information for the type inference algorithm to infer the correct type. It infers that the argument to toList is an empty array of an arbitrary generic type rather than an empty array of integers, and this triggers the unchecked warning described earlier." (The latter is probably referring to the "unchecked varargs" warning.)

That's not true.

It is true that without the type parameter, Sun's javac (1.5 and 1.6) issues a warning: "unchecked generic array creation of type T[] for varargs parameter". But it does not issue an error, which means that it accepts the assignment of the result of Lists.toList() to a variable of type List<Integer> without a cast, which means that it correctly inferred the type Integer for the type parameter T of method Lists.toList().

That an unchecked warning is issued is actually a bug in Sun's javac.

The Eclipse compiler (which generally has fewer generics bugs than javac) compiles the line

List<Integer> ints = Lists.toList();

without any warnings or errors.

Note from the Author or Editor:
Fixed.

The 'copy' method does not close the given streams if an exception occurs. In general, streams should be closed in 'finally' blocks. Additionally, they should be closed in the code block where they were opened, because otherwise even a 'finally' block is not really reliable. For example, if the third line in the second code snippet throws an exception, the stream opened in the second line will remain open. In a nutshell: A code block should close the streams it opens, but no others.

Note from the Author or Editor:
Fixed.

The code snippet contains the method

public static int getCount() { return count; }

This should be changed to

public static synchronized int getCount() { return count; }

The paragraph following the code snippet states "getCount returns the current count", but without synchronization, getCount may return an old value. See the 8th line from bottom on page 161: "Each thread may use a separate memory cache, which means that writes by one thread may not be seen by another unless either they both take place within blocks synchronized on the same lock, or unless the variable is marked with the 'volatile' keyword."

P.S.: In this case, a better solution than 'synchronized' or 'volatile' would be java.util.concurrent.atomic.AtomicInteger.

Note from the Author or Editor:
Fixed.

"abstract class Trust<T extends Trust>"

should be changed to

"abstract class Trust<T extends Trust<T>>"

Note from the Author or Editor:
Fixed!