Registering a listener from its constructor allows the "this" reference to escape
potentially causing concurrency issues.

http://www-128.ibm.com/developerworks/java/library/j-jtp07265/index.html

The implementation of the class CondimentDecorator does not conform to the UML diagram for
the Decorator pattern available on page 91.

In page 91, the UML diagram shows that Decorator *has a* Component, since there is a 'has a' arraw
from Decorator pointing to Component.

In page 92, there is another UML diagram of the Decorator pattern that is adapted to the Starbuzz
case, and it also shows a 'has a' relationship between CondimentDecorator and Beverage.

If the implementation of CondimentDecorator in page 95 were conforming to the Decorator pattern
diagrams in pages 91 and 92 it would be:

/**
* Implementation of CondimentDecorator conforming to pg 91 UML
* diagram of the Decorator pattern
*/
public abstract class CondimentDecorator extends Beverage {
Beverage beverage; // <-- It should have a Beverage instance
// variable to conform to the 'has a'
// relationship shown in the Diagram in pg 91.

/**
* And providing a constructor like this would be adequate:
*/
public CondimentDecorator(Beverage beverage) {
this.beverage = beverage;
}

public abstract String getDescription();
}

The current implementation of CondimentDecorator in page 95 does not conform to the
UML definitions presented in pages 91 and 92, what lets the reader with a confusing
sensation like: "Wasn't I supposed to implement what is shown in the UML diagram definition?",
or "i believe that 'has a' relationship show in the UML can be omitted if I want...".

For your convenince I'm pasting bellow the current implementation of the CondimentDecorator
class currently presented in the book:

public abstract class CondimentDecorator extends Beverage {
public abstract String getDescription();
}

Please fix that.

Diagram shows an US plug, and an British plug and a British wall socket. However the text refers to the British plug and socket as "European".

Not a technical problem, but if someone from the US buys an British travel adapter when visiting (mainland) Europe based on your book, they're going to have a problem :)

Also shows really sloppy research in what is otherwise a fantastic book (and series of books).

Nice overview of plugs can be found: http://users.telenet.be/worldstandards/electricity.htm

On the method compareTo you receive object as parameter and then you make an explicit cast
from object to Duck. But if it was not a Duck ? If it is another kind of object? I thought you
should first test if it is from a compatible type of Duck and then you make the cast.

The code is buggy. (That is why the desserts show up multiple times on p374.) The
reason is that your are creating a new CompositeIterator. When you combine that with
the stack.push statement in method next on p369, you wind up with multiple stacks,
which cause the incorrectly repeated items.

The other problem with your code is that the external iterator doesn't return the
top-level node of the composite. (I.e. your "all-menus" node doesn't get returned.)

These two problems are related. You aren't distinguishing between the iterator
method that the client calls externally, from the createIterator method that gets
called recursively inside the code.

CompositeIterator bug, see also:

http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=9&t=003670

The code is not thread safe for all the reasons you list in the singleton pattern pg 182 .

The ImageIcon reference should be volatile and use java 1.5 + or accessed via synchronized getters and
setters for all Java versions. The issue is its initialised by one thread, written two by another and
then read again by potentially more threads but certainly not the second that loads it.

If you don't in theory the 2nd thread can never see the loaded icon, or see the reference but only the
result of all or part of its construction i.e. you do not have correct memory barriers and therefore no
happens before ordering.

[You also want imageURL to be final post Java 1.4 for the same reasons]

the doGet() should be doPost(), for the JSP on the page 554 that require a doPost() method. the <form method="post" explicitly says so.

the doGet() should also be doPost(), for the JSP on the page 554 that requires a doPost() method.

In order to have the MIDI sound output play continuously you should add the line sequencer.setLoopCount(sequencer.LOOP_CONTINUOUSLY); before starting the sequencer.

Sample program src/headfirst/combined/djview/BeatModel.java;

So

public void on() {
sequencer.start();
setBPM(90);
}

should be :

public void on() {
sequencer.setLoopCount(sequencer.LOOP_CONTINUOUSLY);
sequencer.start();
setBPM(90);
}

In order to have the MIDI sound output play continuously you should add the line sequencer.setLoopCount(sequencer.LOOP_CONTINUOUSLY); before starting the sequencer.

Sample program src/headfirst/combined/djview/BeatModel.java;

So

public void on() {
sequencer.start();
setBPM(90);
}

should be :

public void on() {
sequencer.setLoopCount(sequencer.LOOP_CONTINUOUSLY);
sequencer.start();
setBPM(90);
}