guitar.getBuilder() + " " + guitar.getModel() + " "
should read
guitar.getBuilder() + " " + guitar.getModel() + " " +

on page 6, we use the string "fender"
whereas on page 7, we use the string "Fender" (capital F).

Even if the Inventory.search() were correctly implemented, this difference would mean that we would not find what Erin wants
(the case of the builder string must match)

If I am reading the code on page 82 correctly, the whole example of automatically closing the door is based on the assumption that in normal circumstances (the "main path"), a dog can go outside, do its business, and get back inside within FIVE SECONDS. The note on page 83 says that is "plenty of time to get back inside before the door closes." That is one fast dog!

I kept expecting this to be pointed out as a bug and fixed, but as of the end of chapter 3, it's not. In fact, the code is repeated on page 139.

On page 89, we see the first line of output from DogDoorSimulator.java is:

"Fido barks to go outside..."

Yet this option is missing from the code magnets on page 88, and the magnet is missing from the first line of the solution on page 90.

There is nowhere else this output could have come from; page 83 re-affirms this output should have come from the DogDoorSimulator class.

path 1 and path 6 are identical. The correct answer should thus be that there are six different scenarios, not seven.

We can double-check this since you have two independent choices on the use case, the first of which has two different option (Fido let out by bark recognizer, Fido let out by Todd/Gina), and the second which have three options (Fido not stuck outside, Fido stuck and let in by bark recognizer, Fido stuck and let in by Todd/Gina). two times three equals, again, six scenarios, not seven.

Note says "... it's the SAME class diagram."

Actually, it's not because it does not include BarkRecognizer.

The same thing can be said for the note on page 185.

The output does not match DogDoorSimulator.java.
Example:
"Bitsie" vs. "A small dog"

The arrow from Attribute should point at "Equivalent to a member variable in a class." and the arrow from Operation should point to "This is the UML term that usually represents a method in one of your classes."

In the class diagram shown, class Inventory is associated to class Guitar and holding a reference to the Guitar class. The reference is named "inventory" in the class diagram by mistake (I suppose). It should have been named "guitar"

The same error is there in the very next page..

And on page no 205, class Inventory is holding a reference named "inventory" to abstract class "Instrument". The reference must have been named "instrument"

Yes you allow for re-opening the door if Fido is stuck outside, but it's confusing to see that described as the "alternate path" (when something goes wrong) since it would pretty much always be used.

on the Guitar Class 'inventory *' -> 'guitars *'

The line

Mandolin mandolin = (Mandolin)i.next();

in

public List search(MandolinSpec searchSpec)

will fail at runtime if the Instrument returned by next() is of type Guitar. A instanceof check is required before the casting is done (in both search methods - the Mandolin search as well as Guitar search)

A call to getUnits() is going to die at runtime with a ClassCastException--the objects in the iterator aren't Units, they're Map.Entrys.

How about:
public List getUnits() {
List unitList = new LinkedList();
for (Iterator i = units.entrySet().iterator(); i.hasNext(); ) {
Unit unit = (Unit) ((Map.Entry) i.next()).getValue();
unitList.add(unit);
}
return unitList;
}

Or (less hideously) iterate over values() and use new-style for syntax:
public List getUnits() {
List unitList = new LinkedList();
for (Unit i: units.values()) {
unitList.add(i);
}
return unitList;
}

Or simply rely on the fact that values() gives us a Collection and we can construct a LinkedList directly from a Collection:
public List getUnits() {
return new LinkedList(units.values());
}