Rating: 

<blockquote>

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

</blockquote>

These are only common mistakes that generally did not fit in other chapters. I could have easily entitled the section Miscellaneous Commons Mistakes. The entire book is about common mistakes. The one you are referring to is addressed later in the book.

<blockquote>

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.

</blockquote>

Again, the duality of hashCode() / equals() is tackled later in the book. Second of all, hashCodes() are also addressed quite deeply. The default hashcode method on java.lang.Object generates a hash code based upon the memory location of the object. This is NOT a good hash code to keep and I can give 10,000 other references of people that agree (not least of all Bloch). Hash codes should be indicative of what is inside the object. Furthermore, when you override equals you must override hashcode and overriding it to refer to the base class method would not be a good idea at all.

<blockquote>

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)

</blockquote>

Generating types is one potential solution to the problem. Unfortunately it leads to a lot of code bloat that java can not well afford given its performance. It is also difficult to maintain unless you are using a generation mechanism. Returning unmodifiable collections is a low-cost, high value solution. However, it has more impact than merely preventing junk in the collections. It also has the advantage of firming up encapsulation. Even with the advent of generics (which makes putting junk in collections not impossible but more difficult) returning unmodifiable collections is still a good practice.

<blockquote>

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

</blockquote>

I respectfully request and submit that you should have read further, indeed the whole book, before making a review. Its quite easy to glance through content of a book and find parts you dont like. Furthermore, it is always easier to crab other people's work than to put up your own to be crabbed. Therefore you should be careful what you say about other people's work.

I think that if you read further in the book, you might find many of your questions answered and you might learn many things you never considered before.