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   
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   
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
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 
Printed
Page 16
3rd line

"Collections" should be "Collection"

Anonymous   
Printed
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.

Anonymous  Jul 24, 2008 
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
Printed
Page 23
The 2 code blocks in the middle of the page.

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

Note from the Author or Editor:
Fixed.

Anonymous  Jul 26, 2008  Feb 01, 2009
Printed
Page 31
first line

"more-advanced" should be "more advanced"

Anonymous   
Printed
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 35
compile-time error entry

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

Anonymous   
Printed
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
Printed
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
Printed
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 
Printed
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
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
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   
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
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
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
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
Printed
Page 152
Figure 10.1

"ConcurrenNavigableMap" should read "ConcurrentNavigableMap"

Anonymous   
Printed
Page 159
2nd last paragraph

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

Anonymous   
Printed
Page 162
second full paragraph

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

Anonymous   
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