Errata

Java Generics and Collections

Errata for Java Generics and Collections

Submit your own errata for this product.

The errata list is a list of errors and their corrections that were found after the product was released. If the error was corrected in a later version or reprint the date of the correction will be displayed in the column titled "Date Corrected".

The following errata were submitted by our customers and approved as valid errors by the author or editor.

Color key: Serious technical mistake Minor technical mistake Language or formatting error Typo Question Note Update

Version Location Description Submitted By Date submitted Date corrected
Printed
Page xiv
Obtaining the Example Programs section

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.

Anonymous   
Page Chapter 3 (Comparison and Bounds): Covariant Overriding
The block of code that outlines the definition of the class Object.

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

should be replaced with

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

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

Anders Granlund  Mar 15, 2023 
Page Chapter 4 (Declarations): Static Members
First paragraph.

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.

Anders Granlund  Mar 15, 2023 
Page In many of the code examples.
In many of the code examples.

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.

Anders Granlund  Mar 26, 2023 
Printed
Page 4
last code snippet

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

Anonymous   
Printed
Page 5
middle of the page

"guaranteee" should read "guarantee"

Anonymous   
Page 7
Second Sentence

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.

Anonymous   
Page 7
left column of table of Primitive and Reference types in Java

Primitive type should be boolean, not bool.

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

Anonymous   
Page 7
3rd paragraph

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

Anonymous  Jul 26, 2009 
Page 7
5th paragraph

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.

Anonymous  Jul 26, 2009 
Page 7
1st paragraph

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

Anonymous  Oct 31, 2009 
Printed
Page 7
second code snippet

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.

Anonymous  Jul 26, 2008  Feb 01, 2009
Page 9
4th paragraph


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.

Anonymous  Jul 26, 2009 
Printed
Page 12
2nd code snippet and 3rd paragraph

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.

Anonymous  Jul 26, 2008 
Page 12
code snippet, fourth line

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

Note from the Author or Editor:
Fixed in 2e

Anonymous   
Page 12
code snippet 1

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.

Anonymous  Jul 27, 2009 
Printed
Page 16
3rd line

"Collections" should be "Collection"

Anonymous   
Page 16
3rd code snippet

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

Anonymous   
Page 16
Last sentence

The order of the two words "List<Integer>" and "List<Number>" in the last sentence of page 16
should be swapped, because it should be saying that List<Number> is not a subtype of
List<Integer>.

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

Anonymous   
Page 19
First line

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

{19} First line;
"...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.

Note from the Author or Editor:
This is correct.

Anonymous  Jul 24, 2008 
Page 19
line 2

"as required by the super" should be "as required by the super wildcard"

Note from the Author or Editor:
Fixed in 2e

Anonymous   
Printed
Page 19
line 2

"as required by the super" should be "as required by the super wildcard"

Note from the Author or Editor:
Fixed.

Anonymous  Jul 26, 2008  Feb 01, 2009
Page 21
Last code snippet - third line

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

Anonymous   
Page 22
second para, after code sample

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

Anonymous   
Page 23
The 2 code blocks in the middle of the page.

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.

Anonymous   
Page 24
3rd paragraph

"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

Anonymous   
Page 27
4th paragraph

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

Ravindra Ranwala  Mar 25, 2020 
Page 29
4th paragraph

Change "at" to "as" in "elements from the inner lists at any other type".

Note from the Author or Editor:
Fixed in 2e

Anonymous   
Page 29
Last example

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

Ravindra Ranwala  Mar 25, 2020 
Page 30
Last paragraph

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

Note from the Author or Editor:
Fixed

Maurice Naftalin  Sep 11, 2015 
Printed
Page 31
first line

"more-advanced" should be "more advanced"

Anonymous   
Page 31
3.1 2nd paragraph "The compareTo method..."

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

Anonymous   
Page 32
2nd to last paragraph

"Comparison differs from equality in that >>is<< does not accept a null argument"

>>is<< should be "it" or "Comparison" or "the former"

Note from the Author or Editor:
Fixed in 2e

Anonymous  Sep 10, 2013 
Page 33
5th last paragraph

The sentence "Every value is compares as the same as itself" does not make sense.

Note from the Author or Editor:
Fixed in 2e

Anonymous   
Page 33
after first example

What property is being generalized here? How can x<y iff y<x

Note from the Author or Editor:
Fixed in 2e

Anonymous   
Page 33
3rd para from bottom of page

The paragraph starts "However, it is always required..."

Omit the word "is" in the second sentence, "Every value [is] compares as the same as itself:"

Note from the Author or Editor:
Fixed in 2e

Thomas Costick  Mar 08, 2011 
Page 33
several places

The two occurrences of "this generalizes the property for integers" could be replaced by the more general "this generalizes the property for numbers", which is also used on the page.

Note from the Author or Editor:
Fixed.

Anonymous  Jul 26, 2008  Feb 01, 2009
Printed
Page 34
Last code block

Sign of comparison is wrong ("")

Maurice Naftalin
 
Dec 02, 2013 
Printed
Page 35
compile-time error entry

should be 3.14 not 3,14 since that is not the compile error being demonstrated

Anonymous   
Page 35
4th paragraph

lnteger should be Integer (it starts with a lower-case L)

Note from the Author or Editor:
Fixed in 2e

Anonymous  Sep 10, 2013 
Page 36

Example 3-1 and example 3-2 have the wrong order in the text!

Note from the Author or Editor:
Fixed in 2e

Randolf Rothfuss  Aug 03, 2012 
Page 36
section 3.3 - 2nd paragraph

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.

Ravindra Ranwala  Mar 26, 2020 
Page 37
Comparator

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

Anonymous   
Page 37
5th paragraph

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

sateesh  Jan 05, 2010 
Page 38
class Fruit

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

Anonymous   
Page 41
last paragraph

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

Anonymous   
Page 41
2nd code snippet

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

sateesh  Jan 06, 2010 
Page 42
3rd para from bottom

"panic.Actually" should be "panic. Actually"

Note from the Author or Editor:
Fixed in 2e

Anonymous  Sep 23, 2013 
Page 42
last code snippet, 2nd line

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.

Anonymous  Jul 26, 2008  Feb 01, 2009
Page 47
code snippets

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.

Anonymous  Jul 26, 2008  Feb 01, 2009
Page 48
2nd paragraph from bottom

The paragraph explains the code example 3.6, but has the "first" and "second" method the wrong way around.

Note from the Author or Editor:
Fixed.

Anonymous  Jul 26, 2008 
Page 50
4th paragraph

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.

Anonymous  Jul 26, 2008  Feb 01, 2009
Printed
Page 54
code snippet in middle of page

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.

Anonymous  Jul 26, 2008  Feb 01, 2009
Page 56
Section 4.4 on Erasure, after the "class Overloaded" code snippet

In the discussion of erasure and method overloading, it is stated that the return type of the methods (in this case the method sum()) distinguishes two methods from each other. This is a Java 1.5 compiler bug addressed by Java Sun Bug ID: 6182950. The class Overloaded should generate a compile warning when this bug is fixed, since due to erasure both sum() methods have the same name and same argument list, and therefore are indistinguishable. In general, method return types cannot be used to distinguish between overloaded methods.

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

Anonymous  Jun 29, 2010 
PDF
Page 56
First bullet point

"Appendable & Closeable" should be in fixed-width font.

Philip Wadler  Jan 15, 2015 
PDF
Page 56
Last paragraph before final display

"However, say we change the methods so that each appends its result to the end of the
argument list rather than returning a value:" -->
"However, consider a different pair of methods, which check whether every element of a list
of integers is zero, or whether every element of a list of strings is the empty string."

Philip Wadler  Jan 15, 2015 
Page 58
ninth bullet point

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

Anonymous   
Page 59
sample listing Overloaded2

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.

Anonymous   
Page 78
Paragraph before the last

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.

Ravindra Ranwala  Apr 06, 2020 
Printed
Page 81
4th paragraph

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.

Anonymous  Jul 26, 2008  Feb 01, 2009
Page 84
excerpt of code

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.

Anonymous  Dec 04, 2013 
Printed
Page 86
first line of first full paragraph (after code snippet)

"unchecked cast to T()" should read "unchecked cast to T[]"

I.e., the square brackets were mis-typed as paranetheses.

Anonymous   
Page 87
Example 6.1 DeceptiveLibrary

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.

Ravindra Ranwala  Apr 07, 2020 
Page 91
Last example

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.

Ravindra Ranwala  Apr 10, 2020 
Printed
Page 93
7th line from bottom

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.

Anonymous  Jul 26, 2008  Feb 01, 2009
Printed
Page 99
second paragraph

There's an exclaimation point in the middle of the phrase "generics!for reflection"

Anonymous   
Printed
Page 100
1st paragraph

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 .

Anonymous  Jul 26, 2008  Feb 01, 2009
Page 103
Chapter 7.3 paragraph 3

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.

Anonymous   
Page 104
Example 1.7, line 8

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.

Valentin Baca  Apr 07, 2013 
Page 114
2nd senetence

The sentence
"Array creation, instance tests, and casts nowpose no problems, ..."

"nowpose" probably should be "now pose"

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

Anonymous  May 16, 2012 
Page 119
3rd paragraph, first line

thiry-three should be thirty-three

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

Svein Egil Nilsen  Aug 31, 2009 
Printed
Page 120
3rd line from bottom

"by the sublist method" should be "by the subList method".

Note from the Author or Editor:
Fixed.

Anonymous  Jul 26, 2008  Feb 01, 2009
Page 128
line 9 after 9.3

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.

Jan de Ruiter  May 26, 2010 
Page 128
9.3 Function, 1st paragraph

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.

Ravindra Ranwala  Dec 02, 2020 
Printed
Page 132
2nd paragraph from bottom

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.

Anonymous  Jul 26, 2008  Feb 01, 2009
Page 133
10th line from page's top (conting blank lines too)

In class Functions, method List<B> applyAll(List<A> list) signature should be missing a second
parameter: Function<A, B, X extends Throwable> f and the code 2 lines below should
be ...result.add(f.apply(x));

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

Anonymous   
Page 133
Entire page

Example 9.5 on page 133 does not match the text surrounding it and does not compile.

The text describes a single abstract class. The example is an interface and a separate class
with static methods. Additionally, the applyAll method is written as if it were part of the an
abstract Function class (as described in the text), but it is actually a non-static method of
the separate Functions class. It is referenced in a static context by the Functions class.

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

Anonymous   
Printed
Page 137
last paragraph

"expects an arguement" should be "expects an argument"

Anonymous   
Printed
Page 137
last paragraph

"expects an arguement" should be "expects an argument"

Note from the Author or Editor:
Fixed.

Anonymous  Jul 26, 2008  Feb 01, 2009
Printed
Page 139
last code snippet

"abstract class Trust<T extends Trust>"

should be changed to

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

Note from the Author or Editor:
Fixed!

Anonymous  Jul 26, 2008  Feb 01, 2009
Page 143
21st line

public void update(S o, A a);

surely the 'o' makes more sense as an 's'

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

mat  Aug 15, 2009 
Page 151
Second paragraph

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

Emanuel Frua  Mar 04, 2016 
Printed
Page 152
Figure 10.1

"ConcurrenNavigableMap" should read "ConcurrentNavigableMap"

Anonymous   
Page 154
Example 11.1

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!

Anonymous   
Page 154
2nd para

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.

Anonymous  Feb 03, 2010 
Printed
Page 159
2nd last paragraph

Remove "the" from "This is particularly true for the a graphical user interface".

Anonymous   
Page 160
implementation of pop()

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.

Pete_Clark  Jul 07, 2013 
Printed
Page 162
second full paragraph

The apostrophy in "collection's" appears as a registered trademark symbol.

Anonymous   
Page 163
3rd, 4th and 5th example code fragments

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.

Ravindra Ranwala  May 01, 2020 
Page 167
2nd paragraph

Note that phoneTuesdayTasks has the type List<Task> , while tuesdayPhoneTasks has the
more precise type List<PhoneTask> .

The two occurrences of List should be replaced with Collection.

Note from the Author or Editor:
Fixed in new edition

Ravindra Ranwala  May 05, 2021 
Page 170
last paragraph

"used to by ordered collections"
should read
"used by ordered collections"

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

Anonymous   
Page 170
top of page

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.

Anonymous   
Page 172
2nd paragraph, last line

Missing space.
methodCollections.addAll
should be
method Collections.addAll

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

Svein Egil Nilsen  Sep 02, 2009 
Page 176
first paragraph of section 12.3

"We will go on to look at these three main kinds"
"these" does not refer to anything mentioned previously.
Better would be
"We will go on to look at the three main kinds"

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

Anonymous   
Page 181
Figure 13.3

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.

Anonymous   
Page 182
second full paragraph

In the sentence "These are snapshot iterators; they reflect the state of the set at the time it
was created," the pronoun "it" should be referring to each iterator, but that's not how the
English reads. The english suggests that iterators reflect the state of the set at the time the
set was created, rather than at the time each iterator was created.

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

Anonymous   
Page 184
Last paragraph

In the last paragraph, second sentence says,

Computing trees borrowa lot of their terminology from genealogical trees, ...

And this has a typo, hence should be corrected as below.

Computing trees borrow a lot of their terminology from genealogical trees, ...

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

Ravindra Ranwala  May 05, 2020 
Page 192
code snippets at bottom of page

Some of the source markup is leaking through into the rendered text. The words "verb
$NavigableSet$" and "verb$TreeSet$" should presumably be unadorned (i.e. just "NavigableSet" and
"TreeSet").

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

Anonymous   
Page 192
Figure 14-1. Queue

There's no method called removed() in Queue interface, rather it should be remove()

Note from the Author or Editor:
Figure dropped from 2e.

Ravindra Ranwala  May 10, 2020 
Page 194
Last paragraph

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.

Ravindra Ranwala  May 10, 2020 
Page 205
1st paragraph

The first sentence of the first paragraph says,

Most queue operations respect delay values and will treat a queue with no unexpired elements as if it were empty.

But it should be something like this:

Most queue operations respect delay values and will treat a queue with no expired elements as if it were empty.

So, it should be expired elements, not unexpired elements, that suits the current context.

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

Ravindra Ranwala  May 12, 2020 
Page 207
4th paragraph

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

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

Anonymous   
Page 207
last paragraph

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.

Anonymous   
Page 211
Last paragraph

In the middle of the paragraph, it says,

Their performance characteristics in Figure 14-1 are the same,

In fact, it should be Table 14-1, not Figure 14-1. So, the correct phrase would be,

Their performance characteristics in Table 14-1 are the same,

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

Ravindra Ranwala  May 13, 2020 
Page 218
First example

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.

Ravindra Ranwala  May 14, 2020 
Page 219
Last example

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.

Ravindra Ranwala  May 18, 2020 
Page 220
Last paragraph

The first sentence of the last paragraph says,

As we mentioned in the discussion of ArrayBlockingQueue (Section 14.2), ...

In fact, ArrayBlockingQueue is discussed in Section 14.3.

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

Ravindra Ranwala  May 18, 2020 
Page 223
2nd paragraph

Second sentence reads "It optimizes read access, in line with one of our requirement." The last word should be plural, and it should probably read "It optimizes read access, in line with one of our requirements."

Note from the Author or Editor:
Thanks for reporting this error. It is fixed, along with (I hope) all other reported errors, in the second edition, due out in 2025 Q2.

Pete_Clark  Jul 09, 2013 
Page 227
1st paragraph of section 15.3

The sentence

"Even though the choice here is much narrower than with lists or even sets, ..."

probably should be

"Even though the choice here is much narrower than with queues or even sets, ..."

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

Anonymous   
Page 229
First example

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.

Ravindra Ranwala  May 20, 2020 
Page 232
Last line of the 2nd paragraph

Deletions are trickier than with chaining; if key2 and value2 were removed from the table in Figure 13-2, key3 and value3 would have to be moved along to take their place. The Figure 13-2, is wrong and should be corrected as Figure 16-4

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

Ravindra Ranwala  Jul 01, 2021 
Printed
Page 242
last paragraph

The phrase

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

should read

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

Anonymous   
Page 245
under 16.5.1

The book states iterators (of concurrent Map implementations - not clear, the section is about
ConcurrentSkipListMap, but in previous sections nothing is said about iterator of ConcurrentHashMap) are
fail-fast. According to Javadoc, they are weakly consistent:
java.sun.com/javase/6/docs/api/java/util/concurrent/ConcurrentSkipListSet.html
"Iterators are weakly consistent, returning elements reflecting the state of the set at some point at or
since the creation of the iterator. They do not throw ConcurrentModificationException."
java.sun.com/javase/6/docs/api/java/util/concurrent/ConcurrentHashMap.html
"Iterators and Enumerations return elements reflecting the state of the hash table at some point at or
since the creation of the iterator/enumeration. They do not throw ConcurrentModificationException."

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

Anonymous   
Page 247ff
Chapter 17

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.

Anonymous