Rating: 

1. common mistakes (ch1)

only 2 of them !

the talk about if, if, else is a programming issue not a java issue

how about if(name == "dave") thats a common java error

2 collections

"override hashcode becuase if you dont you will get bad bucket distributions" This is totally wrong - java.lang.util.HashMap specifically guards against poorly randomized hash codes. THis is a terrible piece of advice since it will make people move from the default hashing system (which is highly tuned to be efficient) to one in which most people will generate poor hashes (probably slowly)

You MUST override hashcode and equals in pairs. And you MUST do it if your object semantics are not those of object identiy. I.e it is posisble that for your class objecta == objectb based on their contents. So if the object represents an Order then you need to hash and do equals check on the order number.

3. Avoiding putting junk in collections

THe solution proposed is classically a bad design. The user of the customer class was able to 'corrupt' the orders set. This is because its the wrong design. You are exposing your inner plumbing to the caller by returning a naked Set. Either return an instance of CustomerOrders and have add(Order order) on it or have an addOrder(Order order) on the Customer object. Have the compiler do the check for you (as you advocate somewhere else)

These were the first threee things I read - I stopped reading after that