States that reference type is any "class, instance, or array type." The Java Specification says
that there are three reference types: "class types, interface types, and array types." Therefore
replace instance with interface.

Primitive type should be boolean, not bool.

the line

If an expression e of type in appears where a value of type Integer is expected, boxing converts it to new Integer(e) (however, it may cache frequently occuring values).

should be changed to

If an expression e of type in appears where a value of type Integer is expected, boxing converts it to Integer.valueOf(e) (valueOf method may cache frequently occuring values).

The paragraph

In practice, the compiler will arrange for the value of new Integer(1) to be cached, as we explain shortly.

may be removed, or replaced with

In practice, at runtime the valueOf method uses cached values for some of the wrapper classes.

"A reference type is any class, instance, or array type."
...should be...
"A reference type is any class, interface, or array type."

The foreach loop can be applied to any object that implements the interface Iterable<E>(in package java.lang), which in turn refers to the interface Iterator<E> (in package java.util).

may be replaced with

The foreach loop can be applied to any object that implements the interface Iterable<E>(in package java.lang). The Iterable<E> contains a method iterator() which returns Iterator<E> (in package java.util).

the rightmost parenthesis must be removed or else the code won't compile

the use of toString() in the assert is slightly dangerous.
since we are relying the implementation of toString of the ArrayList
which is not a method appearing the List interface, and description
of toString exists for ArrayList. There is a chance of someone
mistyping the spaces and the comma positions in the String used
for assertion.

A list which is created by method Arrays.asList(T...) cannot be manipulated via method add() of
interface List. So line 3 in this code snippet would cause a
java.lang.UnsupportedOperationException at runtime.
I know that this code snippet would never be runnable because of the compile error in line 2 but
the rest of the code should be as correct as possible.

"...which is a subtype of List<? super Number>..." must be read as "...which is a supertype of
List<? super Number>..."

The following error report (listed on the unconfirmed error reports page) is wrong:

"...which is a subtype of List<? super Number>..." must be read as "...which is a supertype of
List<? super Number>..."

List<Object> is indeed a subtype of List<? super Number>. The quoted sentence is correct as printed in the book.

The section describes the bounding of get and put for generics - "Similarly, you
cannot get anything out from a type declared with an extends wildcard...". I believe
that this should be changed to a "super wildcard".

The code is listed as:

List<Integer> ints = Arrays.asList(1,2,3);
List<Number> nums = ints;
nums.put(2, 3.14);

List<Integer> ints = Arrays.asList(1,2,3);
List<? extends Number> nums = ints;
nums.put(2, 3.14);

Line 2 of the first block is an intended compiler error, but line 3 on both blocks calls a "puts" method
that doesn't appear to be a method of the List interface. I'm assuming a java.util.List is the correct
interface.

In the code snippets, "put" should be changed to "set".

"Arrays of primitive type are much more efficient ... assignments into such an array need not
check for an array store exception, because primitive types don't have subtypes."

As per JLS 3ed 4.10, primitive types ARE arranged in a subtype hierarchy. Array types whose
component types are primitive are not arranged in a subtype hierarchy, so a more accurate clause
would be "because arrays of primitive type don't have subtypes."

This code has

MyList<Object> objs = MyList.<Object>asList("one", 2, 3.14, 4);
MyList<Integer> ints = MyList.asList(2, 4);

I believe both these lines should read

.... = Arrays..... instead of ..... = MyList....

This section correctly notes that the library designers consciously chose not to use the type parameter, E, for Collection<E> in the parameters to the following methods: contains, containsAll, remove, removeAll, and retainAll. The section characterizes this as a backwards compatibility choice. This is incorrect. The example of a legacy client using the test "ints.containsAll(objs)" is irrelevant. In a legacy client, objs would have the raw type Collection so the test would compile and run the same no matter which signature was given to the containsAll method in Java 1.5. The erasure of contains(E) is contains(Object) so the method will look the same to a legacy client. There was no backwards compatibility component to this decision.

The true reason becomes clear when one compares these methods with the methods add and addAll. These methods do make use of the type parameter E. There is an important difference between these two sets of methods. The add and addAll methods add the argument to the collection while the other methods do not. In order to be type safe, these methods MUST include E in their signature. For the other methods no elements are added so the parameters need not have their types restricted in this way.

The last paragraph on page 26 argues that the decision to be more permissive in contains (etc.) might have been the wrong one and claims that if one wants to call contains(E) with an object not of type E one could broaden the type of the collection. While one could argue this point, I think doing so would clearly be too burdensome a requirement. As one example, the client might not control the type of the collection. In that case, if the collection were a known type, at least the client could cast to that type before calling these methods (contains, etc.). However, if the type parameter E is not bound to a known type in the code in question, an unchecked cast to E would be required. By accepting Object instead of E where doing so does not violate type safety the library designers pulled all these considerations inside the implementation, simplifying client code.

The book contains :
"The compareTo method returns a value thatis negative, zero, or positive depending upon whether
the **argument** is less than, equal to, or greater then the given object."

Something is confusing in this sentence.

An extract from the Java API at :
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Comparable.html

int compareTo(T o)

Compares this object with the specified object for order. Returns a negative integer, zero, or a
positive integer as this object is less than, equal to, or greater than the specified object.

Is the "given object" the argument o of type T (bad terminology) ? Or is it the reference on
which the method is called via the dot operator (contradicts the Java contract) ?

Discussing anti-symmetric nature of comparison. Sentence is:
"This generalizes the property for numbers: x < y if and only if y < x."
I think this should be:
"This generalizes the property for numbers: x < y if and only if y > x."

The text says the Comparator interface contains a single method:

public int compare (T o1, t o2);

It contains two methods, the other method being:

public boolean equals(Object obj);

The text states "By the contract for comparators, it would be equivalent to leave the arguments
in the original order but negate the result."

This is not quite true if we take the meaning of "negate" to be "apply the unary minus
operator". The negation of Integer.MIN_VALUE is not representable in a Java int. The value that
results from applying the unary minus operator to Integer.MIN_VALUE is Integer.MIN_VALUE. Since
Integer.MIN_VALUE is a legal return value of Comparator.compareTo, a comparator which simply
applies the unary minus operator to the result of another comparator's compareTo method is not
guaranteed to represent a reverse ordering of that comparator.

The parameter declaration "Comparator<E> comp" should be changed to "Comparator<? super E> comp" to make the method applicable in more cases.

According to the Java Language Specification, 3rd ed, §8.4.2, the signature of a method does not include its return type.

In the first sentence,

"if the signatures match exactly"

should be changed to

"if the signatures and return types match exactly"

In the second sentence,

"if the arguments match exactly"

should be changed to

"if the signatures match exactly"

"The erasures of S and T in the definition of copy are Appendable and Readable, because S has
bound Appendable & Closeable and T has bound Readable & Closeable."

This is incorrect, S and T have been switched. S has bound Readable & Closeable. T has bound
Appendable & Closeable (see page 47). So it should read :

"The erasures of S and T in the definition of copy are Readable and Appendable, because S has
bound Readable & Closeable and T has bound Appendable & Closeable."

Not really a technical mistake, more of an issue in editing. The text says: "However, say we change the
methods so that each appends its result to the end of the argument lis rather than returning a value.",
then the listing for Overloaded2, with two methods:
public static boolean allZero(List<Integer> list) and
public static boolean allZero(List<String> list).

However, neither of those methods:
- are changed versions of previous methods (the previous example used sum() methods that returned a sum
of integers or concatenated Strings);
- appends anything to the argument list.

The line

public boolean empty() { return list.size() == 0; }

should probably be changed to

public boolean empty() { return list.isEmpty(); }

The line

public boolean empty() { return list.size() == 0; }

should probably be changed to

public boolean empty() { return list.isEmpty(); }

The line

public static <T> Stack<T> reverse(Stack<T> in)

should probably be changed to

public static <T> Stack<T> reverse(Stack<? extends T> in)

to make the method applicable in more situations.

As far as I know, C# generics are reified, so the statement "unchecked casts in C# are much more dangerous than unchecked casts in Java" is wrong - there are no unchecked casts in C#.

In the line

newInstance(a.getClass().getComponentType(), c.size());

the expression "c.size()" should be replaced by "size".

(Probably copy & paste error, see the code snippet on page 87.)

The statement "it often is more robust to use equality (the equals method) [than the == operator]" is true in general, but wrong if only Class objects are concerned (as seems to be implied in this paragraph), because java.lang.Class does not overide equals(). If cls1 is a java.lang.Class object, cls1 == cls2 is always equivalent to cls1.equals(cls2), even if multiple class loaders are involved.

Printing History: October 2006 First Edition.

The line says "java.lang.reflect.array.newInstance(int.class,size)", however the class
"java.lang.reflect.array" does not exist in Java 5.0. It should be
java.lang.reflect.Array.newInstance(int.class,size).

Futher, the next paragraph says "... the call returns a value of type int[]". Actually the above
call returns the value of type Object, which can be casted to int[].

Throwable is a checked exception, so the sentence

"An exception is checked if it is a subclass of Exception but not a subclass of RuntimeException"

should be changed to

"An exception is checked if it is not a subclass of RuntimeException or Error"

Example 11.1 is supposed to be "just about the simplest possible example of how
Iterable can be directly implemented." But it's clearly simpler to implement
Iterator<Integer> and Iterable<Integer> together. We can then avoid constructing an
instance of an anonymous class:

class Counter implements Iterator<Integer>, Iterable<Integer> {

private int count;
private int i = 0;
public Counter (int count) {
this.count = count;
}
public boolean hasNext() {
return i < count;
}
public Integer next() {
i++;
return i;
}
public void remove() {
throw new UnsupportedOperationException();
}
public Iterator<Integer> iterator() {
return this;
}
}

List<Integer> l = Array.asList(0,1,2);

should be

List<Integer> l = Arrays.asList(0,1,2);

The curved arrow starting at 'a' should point to 'b' instead of to 'j' and the curved arrow from
'j' to 'b' should point in the reverse direction.

Both occurances of "null" in this paragraph should say "false" instead.

The text states that "the only way of ensuring that variable writes made by one thread are
visible to reads by another is for both writes and reads to take place within blocks
synchronized on the same locks." I think this is incorrect. Declaring the variable as volatile
should also provide the same assurance.

While chapter 17 gives the impression that all the methods of the java.util.Collections class
are described, two methods seem to be missing:

<T> Enumeration<T> enumeration(Collection<T> c)

<T> ArrayList<T> list(Enumeration<T> e)