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. Because of the value of this feedback, I have created several incarnations of a system called “BackTalk” to collect and categorize comments.
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 that 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 all books 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 this language was different from other languages I had seen up to that point.
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 of which 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 cause 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 unmaintainable syntax. Perl is backwards-compatible with Awk, Sed, Grep, and other Unix tools it was meant to replace, and as a result is often accused of producing “write-only code” (that is, after a few months you can’t read it). On the other hand, C++, VB, Perl, 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 that somewhere in the mix of Sun’s design objectives, it appears that there was the goal of reducing complexity for the programmer. As if to say “we care about reducing the time and difficulty of producing robust code.” In the early days, this goal resulted in code that didn’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 many of 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 easy. 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 the Java language designers are working on making it even easier). Network programming is how we talk to each other more effectively and cheaper 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. I think that the results of the communication revolution may 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 that 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 by attempting to teach the language.
Preface to the 3rd edition
Much of the motivation and effort for this edition is to bring the book up to date with the Java JDK 1.4 release of the language. However, it has also become clear that most readers use the book to get a solid grasp of the fundamentals so that they can move on to more complex topics. Because the language continues to grow, it became necessary—partly so that the book would not overstretch its bindings—to reevaluate the meaning of “fundamentals.” This meant, for example, completely rewriting the “Concurrency” chapter (formerly called “Multithreading”) so that it gives you a basic foundation in the core ideas of threading. Without that core, it’s hard to understand more complex issues of threading.
I have also come to realize the importance of code testing. Without a built-in test framework with tests that are run every time you do a build of your system, you have no way of knowing if your code is reliable or not. To accomplish this in the book, a special unit testing framework was created to show and validate the output of each program. This was placed in Chapter 15, a new chapter, along with explanations of ant (the defacto standard Java build system, similar to make), JUnit (the defacto standard Java unit testing framework), and coverage of logging and assertions (new in JDK 1.4), along with an introduction to debugging and profiling. To encompass all these concepts, the new chapter is named “Discovering Problems,” and it introduces what I now believe are fundamental skills that all Java programmers should have in their basic toolkit.
In addition, I’ve gone over every single example in the book and asked myself, “why did I do it this way?” In most cases I have done some modification and improvement, both to make the examples more consistent within themselves and also to demonstrate what I consider to be best practices in Java coding (at least, within the limitations of an introductory text). Examples that no longer made sense to me were removed, and new examples have been added. A number of the existing examples have had very significant redesign and reimplementation.
The 16 chapters in this book produce what I think is a fundamental introduction to the Java language. The book can feasibly be used as an introductory course. But what about the more advanced material?
The original plan for the book was to add a new section covering the fundamentals of the “Java 2 Enterprise Edition” (J2EE). Many of these chapters would be created by my friends and associates who work with me on seminars and other projects, such as Andrea Provaglio, Bill Venners, Chuck Allison, Dave Bartlett, and Jeremy Meyer. When I looked at the progress of these new chapters, and the book deadline I began to get a bit nervous. Then I noticed that the size of the first 16 chapters was effectively the same as the size of the second edition of the book. And people sometimes complain this is already too big.
Readers have made many, many wonderful comments about the first two editions of this book, which has naturally been very pleasant for me. However, every now and then, someone will have complaints, and for some reason one complaint that comes up periodically is “the book is too big.” In my mind it is faint damnation indeed if “too many pages” is your only gripe. (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 acquainted with the vastness of the Java language itself and has not seen the rest of the books on the subject. 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 nonessential. In general, I’ve tried to go over everything, remove from the third edition what is no longer necessary, include changes, and improve everything I could. I feel comfortable removing portions because the original material remains on the Web site (www.BruceEckel.com) and the CD ROM that accompanies this book, in the form of the freely downloadable first and second editions of the book. If you want the old stuff, it’s still available, and this is a wonderful relief for an author. For example, the “Design Patterns” chapter became too big and has been moved into a book of its own: Thinking in Patterns (with Java) (also downloadable at the Web site).
I had already decided that when the next version of Java (JDK 1.5) is released from Sun, which will presumably include a major new topic called generics (inspired by C++ templates), I would have to split the book in two in order to add that new chapter. A little voice said “why wait?” So, I decided to do it for this edition, and suddenly everything made sense. I was trying to cram too much into an introductory book.
The new book isn’t a second volume, but rather a more advanced topic. It will be called Thinking in Enterprise Java, and it is currently available (in some form) as a free download from www.BruceEckel.com. Because it is a separate book, it can expand to fit the necessary topics. The goal, like Thinking in Java, is to produce a very understandable coverage of the basics of the J2EE technologies so that the reader is prepared for more advanced coverage of those topics. You can find more details in Appendix C.
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, so if you carry your laptop, you can put the book on that and add no extra weight to your daily commute. 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 on his Palm in bed 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 a chapter at a time and carry it in their briefcase to read on the train.
