Concurrency

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.

Generics

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).

Schedule

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.