Preface

I suggested to my brother Todd, who is making the leap from hardware into programming, that the next big revolution will be in genetic engineering.

We’ll have microbes designed to make food, fuel and plastic; they’ll clean up pollution and in general allow us to master the manipulation of the physical world for a fraction of what it costs now. I claimed that it would make the computer revolution look small in comparison.

Then I realized I was making a mistake common to science fiction writers: getting lost in the technology (which is of course easy to do in science fiction). An experienced writer knows that the story is never about the things; it’s about the people. Genetics will have a very large impact on our lives, but I’m not so sure it will dwarf the computer revolution (which enables the genetic revolution) – or at least the information revolution. Information is about talking to each other: yes, cars and shoes and especially genetic cures are important, but in the end those are just trappings. What truly matters is how we relate to the world. And so much of that is about communication.

This book is a case in point. A majority of folks thought I was very bold or a little crazy to put the entire thing up on the Web. “Why would anyone buy it?” they asked. If I had been of a more conservative nature I wouldn’t have done it, but I really didn’t want to write another computer book in the same old way. I didn’t know what would happen but it turned out to be the smartest thing I’ve ever done with a book.

For one thing, people started sending in corrections. This has been an amazing process, because folks have looked into every nook and cranny and caught both technical and grammatical errors, and I’ve been able to eliminate bugs of all sorts that I know would have otherwise slipped through. People have been simply terrific about this, very often saying “Now, I don’t mean this in a critical way” and then giving me a collection of errors I’m sure I never would have found. I feel like this has been a kind of group process and it has really made the book into something special.

But then I started hearing “OK, fine, it’s nice you’ve put up an electronic version, but I want a printed and bound copy from a real publisher.” I tried very hard to make it easy for everyone to print it out in a nice looking format but it didn’t stem the demand for the published book. Most people don’t want to read the entire book on screen, and hauling around a sheaf of papers, no matter how nicely printed, didn’t appeal to them either (plus I think it’s not so cheap in terms of laser printer toner). It seems that the computer revolution won’t put publishers out of business, after all. However, one student suggested this may become a model for future publishing: books will be published on the Web first, and only if sufficient interest warrants it will the book be put on paper. Currently, the great majority of books of all kinds are financial failures, and perhaps this new approach could make the publishing industry more profitable.

This book became an enlightening experience for me in another way. I originally approached Java as “just another programming language,” which in many senses it is. But as time passed and I studied it more deeply, I began to see that the fundamental intention of the language is different from all the other languages I have seen.

Programming is about managing complexity: the complexity of the problem you want to solve laid upon the complexity of the machine in which it is solved. Because of this complexity, most of our programming projects fail. And yet of all the programming languages that I am aware, none of them have gone all out and decided that their main design goal would be to conquer the complexity of developing and maintaining programs[1]. Of course, many language design decisions were made with complexity in mind, but at some point there were always some other issues that were considered essential to be added into the mix. Inevitably, those other issues are what causes programmers to eventually “hit the wall” with that language. For example, C++ had to be backwards-compatible with C (to allow easy migration for C programmers), as well as efficient. Those are both very useful goals and account for much of the success of C++, but they also expose extra complexity that prevents some projects from being finished (certainly, you can blame programmers and management, but if a language can help by catching your mistakes, why shouldn’t it?). As another example, Visual Basic (VB) was tied to BASIC, which wasn’t really designed to be an extensible language, so all the extensions piled upon VB have produced some truly horrible and un-maintainable syntax. On the other hand, C++, VB and other languages like Smalltalk had some of their design efforts focused on the issue of complexity and as a result are remarkably successful in solving certain types of problems.

What has impressed me most as I have come to understand Java is what seems like an unflinching goal of reducing complexity for the programmer. As if to say “we don’t care about anything except reducing the time and difficulty of producing robust code.” In the early days, this goal has resulted in code that doesn’t run very fast (although there have been many promises made about how quickly Java will someday run) but it has indeed produced amazing reductions in development time; half or less of the time that it takes to create an equivalent C++ program. This result alone can save incredible amounts of time and money, but Java doesn’t stop there. It goes on to wrap all the complex tasks that have become important, such as multithreading and network programming, in language features or libraries that can at times make those tasks trivial. And finally, it tackles some really big complexity problems: cross-platform programs, dynamic code changes, and even security, each of which can fit on your complexity spectrum anywhere from “impediment” to “show-stopper.” So despite the performance problems we’ve seen, the promise of Java is tremendous: it can make us significantly more productive programmers.

One of the places I see the greatest impact for this is on the Web. Network programming has always been hard, and Java makes it easy (and they’re working on making it easier all the time). Network programming is how we talk to each other more effectively and cheaply than we ever have with telephones (email alone has revolutionized many businesses). As we talk to each other more, amazing things begin to happen, possibly more amazing even than the promise of genetic engineering.

In all ways: creating the programs, working in teams to create the programs, building user interfaces so the programs can communicate with the user, running the programs on different types of machines, and easily writing programs that communicate across the Internet – Java increases the communication bandwidth between people. And I think that perhaps the results of the communication revolution will not be seen from the effects of moving large quantities of bits around. We shall see the true revolution because we will all be able to talk to each other more easily – one-on-one, but also in groups and as a planet. I've heard it suggested that the next revolution is the formation of a kind of global mind which results from enough people and enough interconnectedness. Java may or may not be the tool that foments that revolution, but at least the possibility has made me feel like I'm doing something meaningful here by attempting to teach the language.

People have made many, many wonderful comments about the first edition of this book, which has naturally been very pleasant. However, every now and then someone will have complaints, and for some reason the complaint that comes up most often is “the book is too big.” In my mind it is faint damnation indeed if “too many pages” is your only complaint (one is reminded of the Emperor of Austria’s complaint about Mozart’s work: “Too many notes!” Not that I am in any way trying to compare myself to Mozart). In addition, I can only assume that such a complaint comes from someone who is yet to be acquanted with the vastness of the Java language itself, and has not seen the rest of the books on the subject – for example, my favorite reference is Cay Horstmann & Gary Cornell’s Core Java (from Prentice-Hall) which grew so big it had to be broken into two volumes. Despite this, one of the things I have attempted to do in this edition is trim out the portions that have become obsolete, or at least non-essential. I feel comfortable doing this because the original material remains on the web site and the CD ROM that accompanies this book, in the form of the freely-downloadable first edition of the book (at www.BruceEckel.com). If you want the old stuff, it’s still there, and this is a wonderful relief for an author. For example, you may notice that the last chapter “Projects” is no longer there; two of the projects have been integrated into other chapters and the rest was no longer appropriate. So by all rights the book should be thinner.

But alas, it is not to be.

The biggest issue is the continuing development of the Java language itself, and in particular the expanding APIs which promise to provide standard interfaces for just about everything you’d like to do (and I won’t be surprised to see the “JToaster” API eventually appear). Covering all these APIs is obviously beyond the scope of this book and is a task relegated to other book authors, but some issues cannot be ignored. The biggest of these include server-side Java (primarily Servlets & Java Server pages – JSPs) which is truly an excellent solution to the World Wide Web problem, wherein we’ve discovered that the various Web browser platforms are just not consistent enough to support client-side programming. In addition, there is the whole problem of easily creating applications to interact with databases, transactions, security, and the like which is involved with Enterprise Java Beans (EJBs). These topics are wrapped into a new chapter called Enterprise Programming, a subject that is becoming essential to everyone.

You’ll also find that the networking chapter has been expanded to include Jini (pronounced “genie” and it isn’t an acronym, just a name) and JavaSpaces, two cutting-edge technologies that allow us to change the way we think about interconnected applications. And of course the book has been changed to use the Swing GUI library throughout – again, if you want the old Java 1.0/1.1 stuff you can get it from the freely-downloadable book.

Aside from additional small language features added in Java 2 and corrections made throughout the book, the other major change is in the collections chapter (8), which now focuses on the Java 2 collections, which are used throughout the book. I’ve also improved that chapter to more deeply go into some of the important issues of collections, in particular how a hash function works (so that you can know how to properly create one). There have been other movements and changes, including removal of some appendices that I consider no longer necessary for the printed book, but those are the bulk of them.

For those of you who still can’t stand the size of the book, I do apologize. Believe it or not, I have worked hard to keep it small. Despite the bulk, I feel like there may be enough alternatives to satisfy you. For one thing, the book is available electronically (from the Web site, and also on the CD ROM that accompanies this book), so if you carry your laptop you can carry the book on that with no extra weight. If you’re really into slimming down, there are actually Palm Pilot versions of the book floating around. (One person told me he would read the book in bed on his Palm with the backlighting on to keep from annoying his wife. I can only hope that it helps send him to slumberland.) If you need it on paper, I know of people who print out a chapter at a time and carry it in their briefcase to read on the train.

Another bonus with the 2^nd edition is the CD ROM that is packaged in the back of the book. I’ve resisted putting CD ROMs in the back of my books in the past because I felt the extra charge for a few Kbytes of source code on this enormous CD was not justified, preferring instead to allow people to download such things from my Web site. However, you’ll soon see that this CD ROM is different.

The CD does contain the source code from the book, but it also contains the book in its entirety, in several electronic formats. My favorite of these is the HTML format because it is fast and fully indexed – you just click on an entry in the index or table of contents and you’re immediately at that portion of the book.

The bulk of the 300+ Megabytes of the CD, however, is a full multimedia course called Thinking in C: Foundations for C++ & Java. I originally commissioned Chuck Allison to create this seminar-on-CD-ROM as a stand-alone product, but decided to include it with the second editions of both Thinking in C++ and Thinking in Java because of the consistent experience of having people come to seminars without an adequate background in C. The thinking apparently goes “I’m a smart programmer and I don’t want to learn C, but rather C++ or Java, so I’ll just skip C and go directly to C++/Java.” After arriving at the seminar, it slowly dawns on folks that the prerequisite of understanding C syntax is there for a very good reason. By including the CD ROM with the book, we can ensure that everyone attends a seminar with adequate preparation.

The CD also allows the book to appeal to a wider audience. Even though Chapter 3 (Controlling program flow) does cover the fundamentals of the parts of Java that come from C, the CD is a gentler introduction and assumes even less about the student’s programming background than does the book. It is my hope that by including the CD more people will be able to be brought into the fold of Java programming.

[1] I take this back on the 2^nd edition: I believe that the Python language comes closest to doing exactly that. See www.Python.org.