Contrary to the first sentence, "public Point3D getLocation()" looks perfectly normal
to me. Am I missing somthing, or is the code missing an annotation referred to in the
last sentence: "It's accomplished through the annotation, covered in detail in
Chapter 6."

I don't see an annotation in the code, nor is there one in the downloadable sample
code.

The "Iterating Over Parameterized Types" section on page 19 explains that for/in
loops will not be covered until Chapter 7.

However, a for/in loop is bewilderingly tossed out there in the second code sample on
page 23, with no explanation to the reader as to what it is.

The code snippet of "biggest" is wrong. The code cannot be compiled.
You need to declare type variables like this:

public static <T, U> int biggest(Box<T> box1, Box<U> box2)

valueOf method generated by the javac compiler is a static method. Therefore there is
no way of override.

The description in the "WARNING" is not correct. The static vauleOf method and name
method (defined in Enum class) are mirror images of each other.

"the switch statement (in a different unit)..."
Should it be
"the if statement (in a different unit).

Sentence states "These are all features, and are all represented by powers of two."
The features are not all represented by powers of two. CEDAR, AB_ROSETTE,
AB_TOP_BORDER, and IL_DOTS should be represented by something like 0x08, 0x20, 0x80,
0x100. Otherwise, the bit-wise operations will fail to test for the proper feature.

With Tiger, @SuppressWarnings annotation is not supported by the javac compiler.
Therefore the section titled "Suppressing Warnings" on page 88 through page 90 should
be suppressed or rewritten.

"the compiler then automatically creates member variable with the same name" is not
correct, because the compiler doesn't generate such variables.

There is no type "MethodElement" in java.lang.reflect.
"MethodElement element"
should be:
"Method element" or "AnnotatedElement element"

It's not at all clear what the margin note refers to. I can't see
any reference to LinkedList<string> in the code in Ex. 7-5, 7-6, or
7-7 that the note could refer to.

The sentence "However, this rather simple task is impossible with for/in, because the variable that is used to do all the work, i, is inaccessible in a for/in loop." is completely wrong. It is easy (and IMHO better programming practice) to use for/in to accomplish this "impossible" task, as shown below. Two methods, one using a counted loop (the book's approach), the other using for/in, are presented below for comparison (and in case anyone wishes to actually test or benchmark them, as I did before writing this):

public static String countedJoin(List<String> wordList) {
StringBuilder result = new StringBuilder();
for (int i = 0, len = wordList.size(); i < len; i++) {
if (i < len - 1) {
result.append(wordList.get(i)).append(", ");
} else {
result.append(wordList.get(i));
}
}
return result.toString();
}

public static String iterableJoin(Iterable<String> words) {
StringBuilder result = new StringBuilder();
String currentSeparator = "";
for (String word : words) {
result.append(currentSeparator).append(word);
currentSeparator = ", ";
}
return result.toString();
}

My issues with the book's stated position are:

1) it is factually incorrect, as the above iterableJoin(...) shows,
2) it encourages poor programming:
2a) iterableJoin(...) can be used with more argument data types (List, Set, array, etc., and ANY object that can deliver an iterator),
2b) countedJoin(...) performs very badly if the argument is a LinkedList!
2c) iterableJoin(...) is shorter, faster, and IMHO clearer.

Please let me add that I have a high regard both for O'Reilly in general and for this book! It's just that this particular example is really unfortunate, both in its misinformation and its use of a wrong approach to the task at hand.