Welcome to JavaBeans. After reading this book I hope you'll agree with
me that beans are the wave of the future, and that they make Java
programming easier, more productive, and more fun.When I was finishing up my last book, Java Secrets, John Osborn, one of my editors at IDG, asked me what I thought would make a solid book for IDG's new professional series. "Beans! Let me write about beans!" I practically shouted. It was obvious, even then, that JavaBeans were going to be hot, and that this is where Java was moving. It's four months later; I know a lot more now about JavaBeans than I did then, and I'm more convinced than ever that JavaBeans is going to be an essential part of the future of Java, and indeed of the broader software development world. This book is your introduction to the exciting and fast-growing world of JavaBeans. In this book you'll learn how to write your own unique beans that can be loaded into builder tools to quickly produce powerful and customized applications. I hope you like it.
Thirteen hundred years later, around 850 CE, the Arabic goat herd Kaldi noticed his goats behaving strangely. He thereupon sampled the berries the goats had been eating and discovered both coffee and the stimulating effect of caffeine simultaneously. The coffee bean spread widely from that point, until it was eventually brought to the Indonesian island of Java, and cultivated there in the late 1600's. Eventually the name of the island came to refer to the coffee grown there, then became slang for coffee in general.
In 1995, Sun's Oak language was discovered to suffer from trademark problems. A quick hunt for a suitable name followed, and Java was chosen. From this point forward it became obligatory for Java products to have names based on coffee and/or the culture and geography of the Indonesian archipelago. Thus in 1996 when Sun engineers were casting around for a name for Sun's component software architecture, they settled on JavaBeans.
When Java was first released in May, 1995, it was seen mainly as a tool for including animations and sound and some simple user interaction on web pages, and indeed that's pretty much what it was for the next couple of years. However, from the very beginning many programmers saw that Java had the potential to be something more, the first truly successful object-oriented language that achieved the market share SmallTalk never had and the ease of use and reuse that C++ promised but failed to deliver.
The language itself has changed relatively little since the summer of 1995. Exceptions have been cleaned up, a few features like inner classes have been added, but mostly a pure Java program that doesn't make much use of the API looks pretty much the same now as it did then.
However, although the Java language was very well-thought out and very clean, the same could not be said for the initial class library and application programming interface (API). Java was originally positioned as a language for applets that would run in consumer electronics, smart VCRs and the like. Before being released to the public, it was quickly and haphazardly rewritten to fit into the exploding World Wide Web. It was thought that if the library were powerful enough for users to write small applets, that would be sufficient. Frankly, even for that limited purpose the class library was weak since it provided very limited support for graphics and multimedia compared to more mature environments like PostScript, Director, and OpenStep. And the library was clearly inadequate for more comprehensive applications.
Nonetheless what almost nobody expected but what in fact happened even before applets became common on the Web, was that developers began looking at Java as a replacement for C++, a language whose excessive complexity had destroyed the alleged benefits of object oriented programming.
Given this huge interest in Java from quarters where it was never intended to go, it was clear that the class library and API had to be reworked. One of the things Java needed if it was to become a serious competitor to the likes of C++ and Visual Basic was a component software architecture. It was necessary to allow small pieces of code to be easily combined in a visual tool to produce new applications not envisioned by the original programmers. It was this ability through VBXs that largely accounted for the success of Visual Basic. It was the lack of a standard way of doing this in C++ that in part contributed to the failure of that language. (And make no mistake, despite the millions of lines of C++ code out there, C++ has failed. C++ programs are every bit as buggy, error-prone, late, and hard-to-maintain as programs written in traditional procedural languages like C and COBOL.)
In fact the original Java language was heading down this road before anyone even realized it. Applets are compiled programs that are loaded into an environment at runtime of which no knowledge existed at compile time. This forced certain choices about the design of the Java environment. In particular it required that Java programs be dynamically linked at runtime rather than statically linked at compile time. It also required a class loader mechanism to find the necessary code at runtime whether it resided on a local hard disk or on a remote site somewhere on the Internet.
However, although some of the things a true component software model required were built into Java from the beginning, other things were not. For example's Java 1.0's dynamic class loading was restricted to applets and classes that the applet knew about at compile time. There was relatively little support for a broader introspection that would allow a running program to determine the signatures of all the methods in an arbitrary class and invoke those methods.
Furthermore, Java's event model was closely coupled to the graphical user interface, and all objects that responded to or fired events had to be subclasses of java.awt.Component. Indeed inheritance was overused throughout the class library. This tended to limit programmers' flexibility, especially in a language that did not support multiple inheritance.
And, although classes could be loaded dynamically, there was no simple way to save their state. Every time a class was loaded it was as if it had never been seen or modified before. It was not, for example, possible for a builder tool to load a button, allow the user to change the label of the button, and then save the button with the new label, at least not without manually writing large blocks of serialization code.
Java 1.1 began the process of providing a class library more suitable for a language being used to build large, industrial-strength applications rather than cute applets for web pages.
The java.lang.reflect package was added to allow programs
to dynamically invoke code at runtime, in essence recreating the ability
abandoned years ago with assembly language to write self-modifying
programs (though now it's done in a much cleaner, safer, and
maintainable fashion.) You'll learn about this in Chapter 5.
The old event model, based on inheritance, was abandoned and replaced with a new delegation event model that's cleaner, more robust, easier to understand, easier to extend, faster, and all around more efficient. You'll learn about this in Chapter 6.
A serialization interface and object input and output streams were added so not just raw data but also stateful objects could be saved and restored. You'll encounter this in Chapter 7.
And through all of this ran the thread of JavaBeans. Events are used to communicate between beans. Serialization is used to customize beans. Reflection is used to load unknown beans into runtimes and builder tools and allow them to do their work.
There were other parts too. The
java.sql package and JDBC were added to simplify
interconnection of Java programs and SQL databases. Distributed
computing was added through Remote Method Invocation (RMI) in the
java.rmi package. The security model was enhanced to allow
signed applets and trusted code greater access to system resources.
However, there's little question that in the long run the single biggest improvement to Java in 1.1 and beyond is the JavaBeans component software architecture. While these other packages allow certain, additional specialized programs, JavaBeans is becoming the foundation on which everything else is built. Much as there's currently no reason to separate the Visual Basic language from the various VBXs and ActiveX controls, so too it's soon not going to be apparent what's Java and what's a bean. Many of the 1.0 methods deprecated in Java 1.1 are now replaced by methods that adhere to the established beans patterns. You'll discover that you're already familiar with many beans, that applets and components are themselves now beans. But you'll also learn that beans can be a lot more than that.
Of course, assembling a few beans in a visual builder isn't really sufficiently challenging to justify a book at this level. Therefore I'm also going to show you how to write your own custom beans that you can integrate with third party beans. In fact, this is by far the more difficult and involved of the two goals for this book and will take most of your time and most of my pages.
My other two books are not specifically prerequisites for this
one. Java Network
Programming, (O'Reilly & Associates, 1997), covered
the documented aspects of the java.net package like
URLs, sockets, datagrams, and more. My previous book, Java Secrets, (IDG
Books, 1997), discussed many undocumented and little-known areas
of Java--like the sun classes, native methods, and the virtual
machine. Both of those were a lot of fun to write, and I'll be
extending some of the ideas and examples from those books into
beans in this book. However, when necessary I'll provide
sufficient background for people who haven't read those books to
understand the examples here.
I also hope you'll stop along the way to try out some of the examples and to write some code of your own. It's important to learn not just by reading, but also by doing. For your convenience, complete source code from this book is included on the CD and this web site.
Of course, you're always welcome to skim over material that's already familiar to you. At the end of each chapter you'll find a short summary, you can use to refresh yourself on topics with which you're already familiar.
If I've succeeded in piqueing your interest, you can find JavaBeans: Developing Component Software in Java at almost any bookstore that carries computer books. You can also order it from the online bookstores amazon.com or Computer Literacy. If you need to special order it, the ISBN number is 0764580523. It's $39.99, published by IDG Books, and written by me, Elliotte Rusty Harold.