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.
Hi Bruce! I've been reading Thinking in Java, 3rd Edition and I found it quite important and useful. It's the best book I've ever seen to teach the principles of OOP and the depths of the Java language. I hope Thinking in Java, 4rd Edition will continue in the same way, now with the features of J2SE 1.5.
Bruce, is there any chance of your providing the table of contents of Thinking in Java, 4e? I hope to use it as the primary text for a course starting in mid August and would like to structure the schedule with the order and nature of topics in mind.
I hope to finish the book sometime in August, so I'm not sure if that will work for you. However, here's the current table of contents (the book will actually be cut back to 1400 pages by the time it's done):
Preface 1 Introduction 13 Introduction to Objects 23 Everything Is an Object 61 Operators 93 Controlling Execution 135 Initialization & Cleanup 155 Access Control 207 Reusing Classes 235 Polymorphism 275 Interfaces 311 Inner Classes 345 Holding Your Objects 389 Error Handling with Exceptions 429 Strings 489 Type Information 539 Generics 599 Arrays 685 Containers in Depth 733 I/O 815 Enumerated Types 923 Annotations 971 Concurrency 1021 Graphical User Interfaces 1191 Discovering Problems 1337 A: Guidelines 1427 B: Supplements 1443 C: Resources 1449 Index 1457
You mention your book will be finished sometime in Augest. I am wondering does this implies it goes strict to publishing? ( I saw the release date on Amazon.com is 16th of December 2005, ) Or would you publish it first online to allow reviews and comment for errors and improvement?