Although some of the puzzles fall into the category of "curiosities that you probably won't encounter," it's safe to say that virtually everyone will get some value out of this book. For one thing, Josh is one of the most careful people I know, and I will assume that Neal is also, by association. Neal was heavily involved in the generics implementation. So it's safe to say that the discussions are authoritative.

Both authors were part of the core Java development team at Sun, right up until the release of J2SE5, when both of them left for Google (a number of other core team members left at the same time -- has this phenomenon been analyzed by anyone as to how it relates to Java's future? Please post any links.)

One of the most interesting aspects of the book is what these two, who are about as close to the center of the Java universe as you can get, quietly said at the end of some of the puzzle solutions, in their "lessons for language designers." Which is to say, "if you are designing your own language, here's something you should do instead of what Java did." Which is to say "where Java didn't get it right," in the gentlest possible terms.

Successful Sun marketing efforts have created legions of folks who are happy to believe whatever the Sun marketing flaks say, and who descend like fire ants upon anyone who questions the design of any aspect of Java -- despite the fact that major flaws have been oh-so-carefully revealed by Sun itself. The biggest of these is threading, which has always been broken, up until J2SE5 (we'll have to see, but it seems likely that the issues have been revealed, and probably fixed), which we are all strongly encouraged to upgrade to. There are any number of other questionable design decisions, some large, some small. This is not to say that Java doesn't work reasonably well; what I argue with is when questions are stifled as they tend to be in this community. Not only do we not learn when this happens, but things go backwards because people believe that a design is good when it isn't, or that something is true when it isn't (Years ago, Gosling answered a performance question I asked during a press conference by saying that "Java has always been as fast, or faster, than C++," which naturally left me stumped, since I clearly didn't know by what measure he was making that statement).

Java has obviously moved the programming world forward, but I think its major wart has been the inability of the adherents to look at Java objectively. How else did we end up with EJB1 and EJB2, both of which were based on ivory-tower imaginations of design processes that no one has ever used? (Did anyone else but me get a strange feeling after learning about entity beans and then hearing that you shouldn't use them because they didn't work?) I only heard the full story at a session at the Colorado Software Summit last fall, which introduced EJB3 and explained how we got there. EJBs were the emperor's new clothes in duplicate, and yet the vast majority of people jumped on the bandwagon and created lots of big systems, "because this is the way we build J2EE systems," happily charging clients big bucks to build systems designed around an untried and fundamentally flawed concept, just because Sun marketing had pushed the idea. Who lost? The customers that paid for it. I know personally of systems that were built using EJBs, and then the customer had to pay for another consultant to come in and remove the EJBs to get the system to work right.

Attempts at discussion of the problems of erasure-based generics shows another example of a topic that was decided within Sun and handed to us as a fait accompli. Or consider checked exceptions, a feature that was invented for Java and which has not, to my knowledge, been duplicated in any language since. Despite this, I have not seen any suggestion that Sun considers checked exceptions anything less than the best idea in the world. The list goes on.

In "Effective Java," Josh pointed out a number of places where the language is flawed, and I think it's very valuable that Josh and Neal mention their "lessons for language designers." But it's too bad they don't go further, and begin to clear out the rose-colored fog we have been subjected to for so long by the marketing machine at Sun. The folks who have been breathing that fog do not notice "lessons for language designers" as what they are, a beginning of a critique of Java that might eventually make the language better. If we can't have an intelligent discourse about the flaws in the language, not only will the problems persist, but I think the amount of time that it takes a flawed design to come to light will slow the development of the language and libraries to the point that something else can pull ahead. For example, the EJB problems have taken many years to turn around, because there was no admission of how serious those problems were -- that might have cost vendors money in lost sales, so instead it was the customers who paid, and continue to pay.

  "Programming languages should be designed not by piling
   feature on top of feature, but by removing the weaknesses
   and restrictions that make additional features appear
   necessary. Scheme demonstrates that a very small number
   of rules for forming expressions, with no restrictions on
   how they are composed, suffice to form a practical and
   efficient programming language that is flexible enough to
   support most of the major programming paradigms in use
   today."

>I hope Sun never releases the language spec into the OS
>domain as then those people would go around and actually do
>everything they scream about Sun not putting in like multiple 
>inheritance, surely destroying the language in the process 
>even if the slashdotkiddos whose purpose it is to do so can't 
>pull it off.