Errata

This section is incorrect and needs to be replaced with the proper URL to download the code.

ftp://ftp.oreilly.com/published/oreilly/9780596527754
should be:
http://examples.oreilly.com/9780596527754

Also, the section about ftpmail should be completely removed. We don't have ftpmail service.

class Object {
...
public Object clone() { ... }
}

should be replaced with

class Object {
...
protected Object clone() { ... }
}

Note from the Author or Editor:
Fixed in 2e.

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.

Note from the Author or Editor:
Fixed in the second edition.

In general there are many small errors in the a lot of the examples needs to be fixed before they can be compiled.

Note from the Author or Editor:
Yes. These are all (hopefully) fixed in the second edition, in which all the code will have been compiled.

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.

Note from the Author or Editor:
Fixed in 2e.

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).

Note from the Author or Editor:
Fixed in 2e

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.

Note from the Author or Editor:
Fixed in 2e.

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

Note from the Author or Editor:
Fixed in 2e.

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).

Note from the Author or Editor:
Section dropped in 2e.

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

Note from the Author or Editor:
Fixed in 2e

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.

Note from the Author or Editor:
Changed in 2e to use List equality.

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.

Note from the Author or Editor:
Changed to use new ArrayList<>() in 2e

ints.add(3) is ok at compile-time, but fails to execute at runtime. The reason is that the
ArrayList object returned by the asList() method in the first line comes from an inner class of
the Arrays class, that doesn't implement the add(E e) method, required by the contract of the
List interface. So, the call to Arrays$ArrayList.add(E e) always throws an UnsuportedOperation
exception.

Note from the Author or Editor:
Fixed in 2e

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".

Note from the Author or Editor:
Fixed in 2e

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.

Note from the Author or Editor:
Fixed in the 2e.

"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."

Note from the Author or Editor:
Fixed in the 2e

The method reverse does not compile. The type parameter T should appear before the return type void of the generic method reverse. Here's the method in error.

public static void <T> reverse(List<T> list) {
List<T> tmp = new ArrayList<T>(list);
for (int i = 0; i < list.size(); i++) {
list.set(i, tmp.get(list.size()-i-1));
}
}

And here's the corrected code.

public static <T> void reverse(List<T> list) {
List<T> tmp = new ArrayList<T>(list);
for (int i = 0; i < list.size(); i++) {
list.set(i, tmp.get(list.size() - i - 1));
}
}

Notice that <T> type parameter appears before the return type void of the generic method reverse.

Note from the Author or Editor:
Fixed in 2e

In the last example, the statement calling the generic method missing the target variable name.

List<List<?>> = Lists.<List<?>>factory(); // ok

This should be corrected as List<List<?>> list = Lists.<List<?>>factory(); // ok

Note from the Author or Editor:
Fixed in 2e

The line
class NestedList implements ArrayList<List<?>>{...} // ok
should read
class NestedList extends ArrayList<List<?>>{...} // ok

Note from the Author or Editor:
Fixed

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 :
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) ?

Note from the Author or Editor:
Fixed in 2e

Sign of comparison is wrong ("")

The book says, Following good practice, we have also defined a hashCode method, to ensure that equal objects have the same hash code. But the hashCode method is missing in the given source code. Better include this method in the Frutty example code. Here's a sample.

@Override
public int hashCode() {
int result = name.hashCode();
result = 31 * result + Integer.hashCode(size);
return result;
}

Note from the Author or Editor:
Fixed in 2e.

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

Note from the Author or Editor:
Fixed in 2e

Below is the text that appears in page 37 while explaining the need to modify the type signature of the method "compareTo" to use "super" wildcard :

"The second example shows why this wildcard is needed. If we want to compare two oranges, we take T in the preceeding code to be Orange:"

In the above text "second" example would refer to Example 3.2. But I could verify that even without any modification to method signature "compareTo" i.e even with the signature :
<T extends Comparable<T>> T max
the example 3.2 would work fine.

But with the above signature Example 3.1 reports a compilation error.
So I think the above line in Page 37, needs to be corrected to :

"The first example shows why this wildcard is needed. .."

or better as :

"The Example 3.1 shows why this wildcard is needed.

Note from the Author or Editor:
Fixed in 2e

In the examples on pages 38 and 39, the classes define the "hash" method and call the "hash"
method on a String. This won't compile. Presumably what was intended was to define and call the
"hashCode" method.

Note from the Author or Editor:
Fixed in 2e

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.

Note from the Author or Editor:
Fixed in 2e

The code snippet that creates an instance of Comparator that provides natural ordering (2nd code snippet in page 41) gives compilation error.

I think the corrected code should be something like below :

public static <T extends Comparable<? super T>> Comparator<T> naturalOrder(){
return new Comparator<T>() {
public int compare(final T o1, final T o2) {
return o1.compareTo(o2);
}
};
}

Note from the Author or Editor:
Fixed in 2e

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

Note from the Author or Editor:
Fixed.

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"

Note from the Author or Editor:
Fixed.

"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."

Note from the Author or Editor:
Fixed.

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.

Note from the Author or Editor:
Example removed from 2e.

Another example of the use of unchecked casts to interface legacy and generic code occurred in Section 5.4.1, where we needed an unchecked cast to the element type (E) to make the type of the value returned by the legacy add method match its generic signature.

This paragraph is flawed, since the add method just returns a boolean, not an element of type E. In fact, it is the pop method that returns an element of type E and eventually requires an unchecked cast to E. So, the add method should be replaced with the pop method.

Note from the Author or Editor:
Fixed in 2e.

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#.

Note from the Author or Editor:
Fixed.

1. The method is defined as
public static <T> t[] Array(toCollection<T> c, T[] a){

that should have been

public static <T> t[] toArray(Collection<T> c, T[] a){

Note from the Author or Editor:
Fixed in 1e.

Method intLists, the return variable name should be intLists, not ints. In fact, there's no variable declared with the name ints inside the body of this method. So, this statement is wrong.

return ints;

It should be,

return intLists;

Note from the Author or Editor:
Fixed in 2e.

Method singleton should have it's type variable declared before the return type of the method. The correct declaration should be something like this.

public static <E> List<E> singleton(E elt) {
return Arrays.asList(elt);
}

Note from the Author or Editor:
Fixed in 2e.

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.)

Note from the Author or Editor:
Fixed.

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.

Note from the Author or Editor:
Changed wording to clarify .

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

Note from the Author or Editor:
Fixed in 2e.

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.

Note from the Author or Editor:
Fixed in 2e.

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...'

Note from the Author or Editor:
Section dropped in 2e.

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.

Note from the Author or Editor:
The error report is correct. The error will not appear in the second edition.

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"

Note from the Author or Editor:
Fixed.

"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.

Note from the Author or Editor:
Fixed in 2e.

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

Note from the Author or Editor:
Removed the claim that this is the simplest possible implementation. Questionable whether the proposed alternative solution really is simpler – certainly worse style!

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.

Note from the Author or Editor:
Fixed in 2e.

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.

Note from the Author or Editor:
Fixed in 2e.

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.

Note from the Author or Editor:
Fixed in 2e.

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

should be

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

Note from the Author or Editor:
Fixed in 2e.

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.

Note from the Author or Editor:
Fixed in 2e.

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.

Note from the Author or Editor:
Fixed in 2e.

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.

Note from the Author or Editor:
Fixed in 2e.

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.

Note from the Author or Editor:
Fixed in 2e.

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>();

Note from the Author or Editor:
Fixed in 2e.

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

Note from the Author or Editor:
Fixed in 2e.

The phrase

the platform implementations of NavigableMap.keySet do return a NavigableMap.

should read

the platform implementations of NavigableMap.keySet do return a NavigableSet.

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)

Note from the Author or Editor:
Fixed in 2e.