I recall my first exposure to component programming. Of course we had speculated on such things in the pages of the long-gone visionary magazine Micro Cornucopia, but the first time I actually saw re-usable, visual components in action it was striking. And you generally don't just see components; it's components in combination with a rapid-application development (RAD) environment. When you watch someone pull visual components down from a palette, configure them and connect them and write a little bit of code to produce a program that would have taken you weeks to write by hand, you know this is a giant step forward.
JavaBeans follows in the footsteps of the pioneering languages: Microsoft Visual Basic and Borland's Delphi. Delphi was a second generation of component architecture, set up so that you could actually create the components in the language you were working with, while all previous versions of Visual Basic required you to write components in C or C++. Delphi also significantly refined the component model. But even in Delphi you needed meta-knowledge before you could write components.
JavaBeans is the third-generation architecture for component programming, building on and learning from its predecessors. It's more powerful, but it's also the easiest component programming model to learn since there are no new language concepts or keywords for JavaBeans--a JavaBean is just a class, so once you know how to write classes you can write JavaBeans.
An even more important step forward in component programming is the choice you are allowed with JavaBeans. The JavaBeans design is set up so that a Bean can be used within any application development tool that supports JavaBeans (and a Java development environment that's worth anything will support Beans). This means a better market for Bean vendors since they don't have to worry about where the Bean will be used, and it promotes competition between development tool vendors, which means we (the programmers) win.
So the subject of this book is important. But why am I writing the Foreword? "For the money!" shouts someone in the back of the room. Well, I haven't been in the foreword-writing business for very long so perhaps I don't know all the tricks to getting paid well, but it seems that what they pay for a foreword is nothing short of insulting. So if you're going to write a foreword it's got to be because you like the book, or the author. I like both.
When I started writing my own book (Thinking in Java, freely available at http://www.EckelObjects.com), I was taken in by all the Java hype coming out of Sun: that it was like C++ but so much easier. Well, I knew C++ pretty well and had written a few books on it so I thought, "finally, I can pull that trick where you translate a book in one language into a book in another, and really cash in without doing all the work." Well, that was almost two years ago. It turns out that, although it is easier than C++ in many ways, Java isn't anywhere near as easy as they said.
One reason for this is that the Java team is more ambitious in what they want to accomplish. For example, in C++, multithreading wasn't included because there are multiple models and there didn't seem to be a reason to constrain the programmer to one particular model. Besides, it's possible to get multithreading in a library, so why should it be part of the core language? Java's answer, like its answer to many questions of this type, is "for portability." As time goes on, this becomes a better and better answer (for everyone but Microsoft, whose answer is "why do you care if it runs on anything other than Windows?"). But multithreading is a hard concept to master, even if Java has a simpler model than most. Since multithreading is integral to the language, it makes Java harder to learn, although it also makes you a more powerful programmer. So I spent several months slugging my way through multithreading.
Something that seemed even further afield was networking. All my previous encounters with this subject had been very confusing, and having just muddled my way out of multithreading, I found myself thinking "Is network programming really that important? After all, C++ doesn't have that as part of its library." Wrong thinking, of course. Easy network programming is one of the essential things about Java, but I couldn't see that from any descriptions of networking I'd read. That's when I discovered Elliotte Rusty Harold's book Java Network Programming (O'Reilly, 1996). Here were careful explanations that didn't assume I knew anything at all about networking, and I began to understand what was going on, and to realize that network programming isn't that hard. Not in Java, anyway. In addition, unlike most Java books that have been rushed out and hacked together, Elliotte seemed to get everything right, something I greatly appreciate. It was at this point I became an Elliotte Rusty Harold fan. Along with Cay Horstmann (co-author of Core Java) he is my favorite Java author.
Every few years, some naive and over-enthusiastic computer journalist predicts confidently that programmers should begin looking for other jobs because (name of technology here) will allow computers to do their work without human intervention. Of course such predictions are laughable. However, my suspicions were aroused when I began to look at Elliotte's curriculum vitae. He is, to put it mildly, very productive. So amazingly productive, in fact, that I suspect that he isn't actually a person, but rather a network of computers. If you go to his Web site (Cafe au Lait at http://metalab.unc.edu/javafaq ) you'll see that he somehow keeps track of everything that's going on in the world of Java. I can't seem to do that, so this is one of the few sites I visit every day. And his earlier book was on network programming. See? It all fits.
I think the most important issue for me where computer books are concerned is accuracy. There are so many sloppily made books out there. Usually it's the fault of the editor, who knows and cares nothing about accuracy but is only interested in pushing a book out no matter what the cost. But with an experienced author that puts out sloppy books, after a while you realize they have some other agenda in mind than giving you the reader a valuable learning experience. But like myself, Elliotte Rusty Harold teaches this material, and that puts a whole different slant on things. These are not anonymous book buyers from whom you are trying to extract a few dollars. These are faces you'll see in your classes, and if you don't answer the questions well in your book then you're going to answer them again and again in your classes. I suspect that Elliotte has had the same experiences with teaching as I have, and that is why his writing is so accurate. He knows what's happening in the world of Java, and perhaps more importantly, he always seems to know what's going to happen, so he can steer you in the right direction.
I suppose I can offer no higher praise for this book than to say that I will refer to it when I'm writing my own Beans.
This February (1998), I've convinced Elliotte to speak in the Java Track at the Software Development conference (I am the chair of both the C++ and Java tracks), so I'll finally get to meet him in person. But if someone comes in and starts setting up a network of computers in the room where he's speaking, I'll swallow hard and start looking for a new career in earnest.
Bruce Eckel
President, MindView, Inc.
http://www.MindView.net