Summary
I've just finished reading "Java Puzzlers: Traps, Pitfalls, and Corner Cases" by Joshua Bloch and Neal Gafter (Addison Wesley, 2005).

This is a collection of small, often simple examples that produce (usually) surprising results, along with an appendix of guidelines produced by examining the puzzles. Josh and Neal gave these examples at various Java One conferences, and it was one of the most popular talks there.

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.

Of course, the most important indicator of this trend may simply be that the two authors of this book, along with several other folks who used to be key members of the Java team, no longer work at Sun. Add to that the fact that, so far, J2SE6 looks like a point release (ironically, when we've finally started using whole-number releases) without much of anything exciting in it, and perhaps we can say that Java is now "stable." To be honest, I will be more than glad if that is the case. The 4th edition of Thinking in Java has been a huge project, and much of it seems to come from dealing with difficulties and obscurities rather than showing the power of great new features -- although, happily, there has been a significant share of that.

Talk Back!

Have an opinion? Readers have already posted 7 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Bruce Eckel adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Bruce Eckel (www.BruceEckel.com) provides development assistance in Python with user interfaces in Flex. He is the author of Thinking in Java (Prentice-Hall, 1998, 2nd Edition, 2000, 3rd Edition, 2003, 4th Edition, 2005), the Hands-On Java Seminar CD ROM (available on the Web site), Thinking in C++ (PH 1995; 2nd edition 2000, Volume 2 with Chuck Allison, 2003), C++ Inside & Out (Osborne/McGraw-Hill 1993), among others. He's given hundreds of presentations throughout the world, published over 150 articles in numerous magazines, was a founding member of the ANSI/ISO C++ committee and speaks regularly at conferences.