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. Feedback
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. Feedback
This tutorial 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 tutorial 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 tutorial. Feedback
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 tutorial 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. Feedback
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 uploader.” 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 tutorial. Most people don’t want to read the entire tutorial 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 uploaders out of business, after all. However, one student suggested this may become a model for future publishing: tutorials will be published on the Web first, and only if sufficient interest warrants it will the tutorial be put on paper. Currently, the great majority of all tutorials are financial failures, and perhaps this new approach could make the publishing industry more profitable. Feedback
This tutorial became an enlightening experience for me in another way. I originally approached Java as “just another coding 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. Feedback
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 coding projects fail. And yet, of all the coding 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. Feedback
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. Feedback
One of the places I see the greatest impact for this is on the Web. Network coding has always been hard, and Java makes it easy (and the Java language designers are working on making it even easier). Network coding 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. Feedback
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. Feedback
Preface to the 3rd version
Much of the motivation and effort for this version is to bring the tutorial up to date with the Java JDK 1.4 release of the language. However, it has also become clear that most readers use the tutorial 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 tutorial 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. Feedback
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 tutorial, 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. Feedback
In addition, I’ve gone over every single example in the tutorial 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. Feedback
The 16 chapters in this tutorial produce what I think is a fundamental introduction to the Java language. The tutorial can feasibly be used as an introductory course. But what about the more advanced material? Feedback
The original plan for the tutorial was to add a new section covering the fundamentals of the “Java 2 Enterprise version” (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 tutorial 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 version of the tutorial. And people sometimes complain this is already too big. Feedback
Readers have made many, many wonderful comments about the first two versions of this tutorial, 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 tutorial 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 tutorials on the subject. Despite this, one of the things I have attempted to do in this version 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 version 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 tutorial, in the form of the freely downloadable first and second versions of the tutorial. 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 tutorial of its own: Thinking in Patterns (with Java) (also downloadable at the Web site). Feedback
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 tutorial in two in order to add that new chapter. A little voice said “why wait?” So, I decided to do it for this version, and suddenly everything made sense. I was trying to cram too much into an introductory tutorial. Feedback
The new tutorial 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 tutorial, it can expand to fit the necessary topics. The goal, like Thinking about 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. Feedback
For those of you who still can’t stand the size of the tutorial, 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 tutorial is available electronically, so if you carry your laptop, you can put the tutorial 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 tutorial floating around. (One person told me he would read the tutorial 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. Feedback
Java 2, JDK 1.4
The releases of the Java JDK are numbered 1.0, 1.1, 1.2, 1.3, and for this tutorial, 1.4. Although these version numbers are still in the “ones,” the standard way to refer to any version of the language that is JDK 1.2 or greater is to call it “Java 2.” This indicates the very significant changes between “old Java”—which had many warts that I complained about in the first version of this tutorial—and this more modern and improved version of the language, which has far fewer warts and many additions and nice designs. Feedback
This tutorial is written for Java 2, in particular JDK 1.4 (much of the code will not compile with earlier versions, and the build system will complain and stop if you try). I have the great luxury of getting rid of all the old stuff and writing to only the new, improved language, because the old information still exists in the earlier versions, on the Web, and on the CD ROM. Also, because anyone can freely download the JDK from java.oracle.com, it means that by writing to JDK 1.4, I’m not imposing a financial hardship on anyone by forcing them to upgrade. Feedback
Previous versions of Java were slow in coming out for Linux (see www.Linux.org), but that seems to have been fixed, and new versions are released for Linux at the same time as for other platforms—now even the Macintosh is starting to keep up with more recent versions of Java. Linux is a very important development in conjunction with Java, because it is quickly becoming the most important server platform out there—fast, reliable, robust, secure, well-maintained, and free, it’s a true revolution in the history of computing (I don’t think we’ve ever seen all of those features in any tool before). And Java has found a very important niche in server-side coding in the form of Servlets and JavaServer Pages (JSPs), technologies that are huge improvements over the traditional Common Gateway Interface (CGI) coding (these and related topics are covered in Thinking in Enterprise Java). Feedback
[1] I take this back on the 2nd version: I believe that the Python language comes closest to doing exactly that. See www.Python.org.