Sponsored Link •
To stem the tide of emails asking this question, this entry describes the current state of the book and explains why it's taking so long.
Here's the situation at the time of this writing: There are 23 chapters in the book, and all but 5 of them have been polished and have even gone through copy edit. Except for those 5 chapters, the book is done. Ah, but the 5 chapters are the hard ones. 3 of those chapters require various levels of work to finish, but it's the "Generics" and "Concurrency" chapters that are the big hurdles. I've already spent months on both of them (you can see the struggle over generics reflected in a number of the articles here: http://mindview.net/WebLog), and I hope that by the time I'm ready to tackle them again, the unconscious part of my brain will have magically figured out many of the difficult issues.
Another way to look at it is to say that J2SE5 has made me realize how complex Java has become. It's been sneaking along with the various releases, but J2SE5 (clearly driven by the features in C# 2.0) has leapt forward far enough that you suddenly wake up and say "hey, this isn't a 'simple' language anymore!" (Many will argue that it never was).
For example, I've come to understand that to teach Java now requires a two-week seminar, whereas before I could fit things into a single week. This change has been long in coming, but it was hard for me to break out of a one-week seminar format. It always seemed like a programming language should be acquirable in a single week. It took a customer saying "we just want the basics" for me to (A) figure out what the basics were (in this case, as in many, just enough Java to be able to write servlets and JSPs, and talk to JDBC -- that is, enough to write basic web server applications) and (B) discover that learning Java didn't have to be a painful process for all concerned. Trying to cram too much into too short a time is agonizing for everyone, but like the proverbial frog in the slowly-heating saucepan, the features that were incrementally added to the language always seemed like they could be shoehorned in. It took time and pain to discover that we had passed the point of a one-week seminar.
Although it is largely unheralded, the changes in concurrency for J2SE5 are quite significant. They have resulted in a new set of libraries (although we often treat libraries as secondary to language feature changes, the new concurrency libraries are fundamentally important). Under the covers, there's a new memory model that changes the way Java concurrency is implemented. The theoretical underpinnings for this model have made significant impacts on the programming community in general, and in particular are strongly influencing the concurrency features in the next version of C++.
My initial approach to the new concurrency features was to try to cover everything, and I spent numerous months working on this before discovering that I had a chapter that was over 150 pages long. For awhile I thought of trying to make this a book on its own. During a lunch discussion with Brian Goetz at a conference, I discovered that he was writing a book on the depths of J2SE5 concurrency (which is supposed to be out this fall), and I realized that I could fall back to covering the essentials, and refer to Brian's book for people who need more depth. Now it's a matter of pulling out the extra material, ensuring that I actually do cover the essentials effectively, and finally making sure that everything is correct (no mean feat where threading is concerned). But notice the evolution that was required -- If I had understood from the beginning that there were more and less important library features, and what those features were, it would have been much easier to write the chapter. But like software itself, you usually have to get in and wrestle with the details before the design becomes clear.
The challenge of generics has been at least equal to that of concurrency. Or perhaps greater, as some of the essays at http://mindview.net/WebLog will show. I've been told a number of times, occasionally quite derisively, "oh, you just expected it to work like C++ templates" (usually combined with the party-line attitude that C++ templates are clearly inferior). Indeed, I had expectations, but they were that "generics" in Java would live up to their name, and provide a way to produce code that is applicable across more types, rather than just a way to have better type checking for containers.
The problem is that it's not quite either of these things. If you throw up your hands and say "OK, better containers is what it's all about, now I don't have to worry about upcasting and downcasting," you soon discover situations where generics can allow you to write more effective code which falls outside that description. But as soon as you decide that it's a true generic mechanism, you run into the wall of erasure -- you don't really know what type the generic code is working with. To partially compensate for this, you must introduce bounds, which leads to covariance and contravariance. By comparison, C++ templates are vastly simpler and more powerful; indeed, the only real problem with C++ templates is the horrible error messages that compilers have traditionally produced (The next version of C++ intends to solve this problem quite effectively). So you need to understand why Java generics don't have the power and simplicity of C++ templates (answer: migration compatibility -- using old libraries in J2SE5).
One attitude that people have taken when faced with the complexity of Java generics is to assume that programmers can simply be consumers of generic libraries that other programmers have created. This was a short-lived illusion in the C++ community, as well. My experience is that, once you know about generics, they start wanting to creep into your code, no matter how mundane you think that code is, because the idea of genericity is fundamental to what we try to do in programming. For various understandable reasons, Java's implementation of generics makes it hard to achieve that idea, and so you're faced with a big struggle. And that struggle translates to my struggle in writing the chapter (also, I tried to use generics throughout the book, wherever they were appropriate. This helps improve your familiarity with generic issues).
I had hoped to finish the book at the end of February (the last of a number of dates that I had hoped to finish it by...), at which time I began a fair amount of traveling, including speaking at conferences and a marathon 1-month, 3-company consulting tour. I have not mastered the ability to do these kinds of things and do any significant work on a book at the same time, although I know people who can. I have just returned to Crested Butte, CO, and am digging back into the book again. My current hope is to finish it by the end of the summer. That seems reasonable to me now, but I've never been terribly good at estimating these things.
Because the Hands-On Java CD follows directly from the work in the book, I will be starting work on that when the book completes (using Flash this time, to eliminate platform problems), and I do not intend to miss a cycle as I did with Thinking in Java, 3rd edition. Those of you who have purchased the 2nd edition of the CD since the publication date of Thinking in Java, 3rd edition will automatically get an upgrade to the upcoming edition of the CD, as promised.
Note also that there will be no Thinking in Java CD bound into the fourth edition. The Thinking in C introduction will be reformed into a downloadable Flash presentation, and the source code will also be downloadable -- doing it through the web is now feasible and reasonable, and there were too many problems with the bound-in CD in TIJ3.
|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.|