JavaBeans: Developing Component Software in Java

[ Table of Contents | Examples | Foreword by Bruce Eckel | About the CD | Japanese Edition | Order ]
JavaBeans cover 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.

How Beans Sprouted

The history of beans begins around 500 BCE when the Greek mathematician and mystic Pythagoras founded a religious brotherhood based on the reincarnation of souls, vegetarianism, the mystical significance of numbers, and abstention from the eating of beans. Apparently Pythagoras believed the beans might contain the souls of the dear departed. One possibly apocryphal story reports Pythagoras being killed by an angry mob because he refused to run across a field of beans to escape.

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.

Who You Are

This is not an introductory book about Java. There are over 100 of those. The world doesn't need another. This book assumes that you have a basic knowledge of Java's fundamentals such as objects, classes, methods, loops, arguments, and data types. You should also be able to write graphical applets and applications. You should have some familiarity with both the java.applet and java.awt packages, at least at the level of Java 1.0. To be more specific:

However, since many people now learning Java Beans started with Java 1.0 and are still most comfortable with it, I will cover Java 1.1 topics like the delegation event model in full. In many cases, those methods of Java 1.0 that were deprecated in Java 1.1 were replaced by new methods precisely to meld with the JavaBeans design patterns. In particular this book will teach you:

What You'll Learn

This book has two primary goals. By working your way through it, you should learn:

  1. How to use beans to build applications
  2. How to write new beans
One of the main purposes of JavaBeans is to provide a standard means to easily and quickly assemble large applications out of small components called beans. Before JavaBeans, each Java development tool vendor had its own means of combining different bits of code. After JavaBeans you should not be tied down to one IDE just because you like a few of its custom components.

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.

Who I Am

This is my fourth book about Java. My first book, The Java Developer's Resource (Prentice Hall, 1997), is a general introduction to Java 1.0 for programmers in other languages. If you haven't programmed in Java before, you might want to pick up that book first before reading this one. In many ways that book is the demarcation point for what I will and won't discuss in this book. Topics that were adequately covered there like graphics and basic widgets will not be repeated here. Topics that were not covered in that book (like object serialization) and topics that have changed significantly since that book was published (like the event model) will be dealt with here. Of course the JDR is hardly the only good introductory book on Java 1.0. As you long as you're reasonably comfortable with Java 1.0, you should find this book smooth sailing.

My other two books are not specifically prerequisites for this one. Java Network Programming, (O'Reilly & Associates, 1997), covered the documented aspects of the 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.

How to Use The Book

JavaBeans: Developing Component Software in Java is designed to be read more or less cover-to-cover. Each chapter builds on the material in the previous chapters in a fairly predictable fashion.

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.

Summing Up

JavaBeans is the wave of the future. Writing JavaBeans: Developing Component Software in Java not only taught me about JavaBeans itself. It changed the way I looked at Java programs in general. JavaBeans is not just another API that you can pick up when you need int. Itn is a sea change in the way you look at Java programs and Java programming. And I can think of no better way to learn about it than reading JavaBeans: Developing Component Software in Java. Why don't you check it out, and let me know what you think?

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 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.

Table of Contents

Part 1: Introducing JavaBeans
Chapter 1 Introducing JavaBeans
Chapter 2 Key Technologies
Chapter 3 Opening the BeanBox
Chapter 4 A Simple Bean
Part II: Core Technologies
Chapter 5 The Reflection API
Chapter 6 The Delegation Event Model
Chapter 7 Object Serialization
Part III: Advanced Bean Development
Chapter 8 Analyzing Beans
Chapter 9 Properties
Chapter 10 Customizing Beans
Chapter 11 The URL Bean
Appendix A JavaBeans QuickRef
Appendix B JavaBeans Glossary
Appendix C Additional Resources
Appendix D About the CD

[ Cafe au Lait | Table of Contents | Examples | Foreword by Bruce Eckel | About the CD | Japanese Edition | Order ]

Copyright 1997, 1998 Elliotte Rusty Harold
Last Modified October 20, 1998