Errata

In

"Because generics are compiled by erasure, at run time the classes List<Integer>, List<String>, and List<List<String>> are all implemented by a single class, namely List."

Here List is referred to as a class but it is an interface.

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

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[].

Line 8 of Example 1.7 should be:
Object newobj = obj.getClass().newInstance();
instead of
Object newobj = obj.getClass().getConstructor().newInstance();

There is no "getConstructor()" method in Class and a call to either getConstructor(Class<?>... parameterTypes) or getConstructors() is unnecessary.

The line says: 'An exception is checked if it is a subclass of RuntimeException or Error'. Of course this must be: 'An exception is unchecked...'

The line,

The relation between a function and the corresponding method is similar to the relation between Comparator and the compareTo method.

Comparator has a method named compare but not compareTo. The compareTo method belongs to Comparable. The line should be changed accordingly.

"For example, in the previous expression the first two terms are comparable for low values of N; in fact, for N < 8, the second term is larger."

If N is equal to 7, the first and second terms are equal to 171.50.
It must be N < 7 or N <= 6.

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;
}
}

The 2nd paragraph should indicate that the provided scenario is one (of many) possible non-thread-safe scenarios[1].

Also, I believe the described/intended scenario is also has the wrong logic. For example, here's what I think should happen (timeline-wise):

A: push()
B: push()
... (assume empty stack, here) ...
A: index++ [ex: 0] //1
B: index++ [ex: 1] //1 (presumes index value gets flushed)
B: stack[1] => B_elt //2
A: stack[1] => A_elt //2
...

In the above scenario, A's value will overwrite B's vaule in stack[1] contrary to the text. Also, the text says that the index will have incremented twice (which might equal 1 depending on visibility) and points to whatever was there before. In fact, it should point to A's elt value and not any previous/default value (again assuming the intended scenario takes place).

[1] For example, another possible scenario is that Thread 1 & 2 never "see" each others updates to index causing it to be incremented just once or maybe not even at all.

The implementation of the pop() method for ArrayStack on page 160 is incorrect. The code executed if the 'if' condition evaluates to true reads:

return stack[index];
index--;

but the index decrement will never be executed because control returns to the caller when the return statement is evaluated, leading to incorrect behavior for pop() and an inevitable stack overflow after 10 pushes regardless of how many pops() are called.

Since the implementation is marked as 'non-thread-safe', the two statements could be combined as:

return stack[index--];

Of course, one would want more bulletproof (and genericized) code anyway if one were making a Stack.

The example uses,

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

But the asList method is available in the Arrays utility class. So, it should be:

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

Also the same issue occurs on page 164, first example code fragment too.

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.

The first sentence says,

In the next section we shall look at the direct implementations of Queue - PriorityQueue and ConcurrentLinkedList

In fact, that should be ConcurrentLinkedQueue as per figure 14-2.

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.

The declaration of constant FORWARD_PLANNING_DAYS should have been marked static. Here's the correct declaration:

private static final int FORWARD_PLANNING_DAYS = 365;

The signature of the method getSubschedule is not correct. It's return type should be ListIterator<StoppableTaskQueue> instead of listIterator<StoppableTaskQueue>. The correct version is given in the sample code though.

The last example contains the code fragment,

List<Character>; charList = new ArrayList<Character>();

which is wrong. The semi-colon after the type declaration is not valid and the code does not compile. It should be corrected as below.

List<Character> charList = new ArrayList<Character>();

The class BoundedSizeMap is a raw type. Since the book emphasizes on effective use of generics and collections framework, it is better to use generics there. Here's a sample implementation using generics.

public class BoundedSizeMap<K, V> extends LinkedHashMap<K, V> {
private int maxEntries;

public BoundedSizeMap(int maxEntries) {
super(16, 0.75f, true);
this.maxEntries = maxEntries;
}

protected boolean removeEldestEntry(Map.Entry<K, V> eldest) {
return size() > maxEntries;
}
}

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)