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.
[ Add Comment ]
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.
[ Add Comment ]
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.
[ Add Comment ]
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.
[ Add Comment ]
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.
[ Add Comment ]
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 is different from all the other languages I have
seen.
[ Add Comment ]
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.
[ Add Comment ]
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.
[ Add Comment ]
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.
[ Add Comment ]
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 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 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.
[ Add Comment ]
People have made many, many wonderful
comments about the first edition 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 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 acquainted 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 (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 nonessential. 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 original last chapter, “Projects,” is no longer here; two of the
projects have been integrated into other chapters, and the rest were no longer
appropriate. Also, the “Design Pattens” chapter became too big and
has been moved into a book of its own (also downloadable at the Web site). So,
by all rights the book should be
thinner.
[ Add Comment ]
But alas, it is not to
be.
[ Add Comment ]
The biggest issue is the continuing
development of the Java language itself, and in particular the expanding APIs
that 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
authors, but some issues cannot be ignored. The biggest of these include
server-side Java (primarily Servlets & Java Server pages,
or 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 the chapter formerly
called “Network Programming” and now called “Distributed
Computing,” a subject that is becoming essential to everyone. You’ll
also find this chapter has been expanded to include an overview of Jini
(pronounced “genie,” and it isn’t an acronym, just a name),
which is a cutting-edge technology that allows 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 at
www.BruceEckel.com (it is also included on this edition’s new CD
ROM, bound into the book; more on that a little
later).
[ Add Comment ]
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 (9), which now focuses on the Java 2
collections 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 a rewrite of Chapter 1,
and removal of some appendices and other material that I consider no longer
necessary for the printed book, but those are the bulk of them. In general,
I’ve tried to go over everything, remove from the 2nd edition
what is no longer necessary (but which still exists in the electronic first
edition), include changes, and improve everything I could. As the language
continues to change—albeit not quite at the same breakneck pace as
before—there will no doubt be further editions of this
book.
[ Add Comment ]
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 a chapter at a time and carry it in their briefcase to read on
the
train.
[ Add Comment ]
At this writing, the release of
Sun’s Java Development Kit (JDK) 1.3 is imminent, and the proposed
changes for JDK 1.4 have been publicized. 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
edition of this book—and this more modern and improved version of the
language, which has far fewer warts and many additions and nice
designs.
[ Add Comment ]
This book is written for Java 2. 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
electronic 1st edition on the Web and on the CD ROM (which is where
you can go if you’re stuck using a pre-Java-2 version of the language).
Also, because anyone can freely download the JDK from java.sun.com, it means
that by writing to Java 2 I’m not imposing a financial hardship on someone
by forcing them to upgrade.
[ Add Comment ]
There is a bit of a catch, however. JDK
1.3 has some improvements that I’d really like to use, but the version of
Java that is currently being released for Linux is JDK 1.2.2. Linux (see
www.Linux.org) is a very important development in conjunction with Java, because
it is fast becoming the most important server platform out there—fast,
reliable, robust, secure, well-maintained, and free, 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 programming in the form of Servlets, a technology that is a
huge improvement over the traditional CGI programming (this is covered in the
“Distributed Programming”
chapter).
[ Add Comment ]
So although I would like to only use the
very newest features, it’s critical that everything compiles under Linux,
and so when you unpack the source code and compile it under that OS (with the
latest JDK) you’ll discover that everything will compile. However, you
will find that I’ve put notes about features in JDK 1.3 here and
there.
[ Add Comment ]
Another bonus with this 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.
[ Add Comment ]
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.
[ Add Comment ]
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.
[ Add Comment ]
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.
[ Add Comment ]
[1]
I take this back on the 2nd edition: I believe that the Python
language comes closest to doing exactly that. See
www.Python.org.