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

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.

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.

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 .

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.

The phrase

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

should read

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