(Page 3 of 3 )A walking tour of JavaBeans What JavaBeans is, how it works, and why you want to use it
A walking tour of JavaBeans
What JavaBeans is, how it works, and why you want to use it
Page 3 of 3
All of this interaction between Beans presupposes some way for them to communicate. JDK 1.1 defines a new event model that classes (not just Beans!) use to communicate. In fact, this new event model has found its way into one of Java's most widely-used packages:
In the new event model, a class registers interest in the activities of another class by way of a listener interface. In effect, the target object (the interested party) tells the source object (the object of interest), "Let me know whenever so-and-so happens." When the so-and-so occurs, the source object "fires" an event at the target by invoking the target's event handler with a subclass of
EventObject as the argument.
Events can be used to implement bound and constrained properties. In the PieChart and SpreadSheet example above, the PieChart "registers" interest in any change to the SpreadSheet's (let's say) DataList property. When the SpreadSheet is going to change its DataList property, it passes a
DataListChangedEvent (subclassed from
EventObject), indicating what changed, to every interested listener's event handler method. The target (
PieChart) then examines the event, and takes appropriate action.
The nuclear reactor example works similarly; but in that case, the target vetoes the change by throwing an exception. Thus the world is saved from widespread radioactive destruction.
EventObject class can be extended to create user-defined events. Classes can now define and use new event types to send messages to one another. This means that Beans running inside the same container may communicate by passing messages around. This helps uncouple dependencies between objects, which we know is A Very Good Thing.
User-defined (and other) events are derived from the class
The rather odd term introspection is Java-speak for the process of programmatically analyzing a class's public methods and members. This process is also sometimes called discovery. The new reflection mechanism in the Java core, which can dissect an object and return a description of its contents, makes introspection possible. (Although Java may be reflective, even introspective, omphaloskepsis is still not part of the core distribution.)
We've already run across one application of this capability. Above, we described an IDE that could construct a list of Bean properties to present to a developer. How can the IDE know what properties a Bean has? The IDE discovers a Bean's properties in one of two ways: by asking the Bean for a description of its properties, or by dissecting the Bean by introspecting it.
A typical IDE will start by asking a Bean for a BeanInfo object, which describes the Bean's properties, among other things. The IDE will then use the BeanInfo object to construct a property sheet. (This is assuming the Bean doesn't provide a customizer of its own.) If the Bean doesn't know how to return a BeanInfo object, the IDE then introspects the Bean, and scans the list of methods for names beginning with set and get. It assumes (by convention) that these methods are accessors for properties, and creates a new property sheet based on the accessor methods that exist and the types of the arguments those methods take. So, if the IDE finds methods like
Size getSize(), then it will create a property sheet with the properties Color and Size, and appropriately-typed widgets for setting them.
This means that if a developer simply follows the conventions for naming accessor methods, an IDE can determine automatically how to create a customization property sheet for the component.
The reflection mechanism that performs introspection is in the new language core package
Persistence and packaging
It's often useful to "freeze-dry" an object by converting its state into a blob of data to be packed away for later use -- or transmitted through a network for processing elsewhere. This process is called serialization and is a new feature of the Java core.
One of the simplest uses for serialization is to save the state of a customized Bean, so that a newly-constructed Bean's properties can be correctly set at run time.
Also, serialization is a mainstay of component technology, making possible distributed-processing schemes such as CORBA. If an object doesn't have the information locally that it needs to perform its task, it can send itself to a Request Broker, which serializes the object and sends it elsewhere for processing. On the remote end, the object is reconstituted and the originally-requested operation is performed. This is also a way to realize load balancing (for expensive tasks, that is: serialization and deserialization often aren't cheap).
Where do you keep a group of freeze-dried Beans that have been "pickled" in this way? Why, in a JAR, of course! The JavaBeans specification describes a JAR file as a structured ZIP file containing multiple serialized objects, documentation, images, class files, and so on, with a manifest that describes what's in the JAR. A JAR file, containing many compressed small files, can be downloaded all in one piece and decompressed on the client end, making applet downloading (for example) more efficient. (JAR is pretty obviously a play on the Unix tar file format.)
Some wag once said that the nice thing about standards is that there are so many to choose from. Component technologies are no exception. There are many existing systems based on OLE (or its latest incarnation, ActiveX), OpenDoc, and LiveConnect. JavaBeans has been designed to (at least eventually) interoperate with these other component technologies.
It's not realistic to expect developers to abandon existing investments in other technologies and reimplement everything in Java. Since the release of Java 1.1, the first Beans/ActiveX "bridge" kits have become available, allowing developers to link Beans and ActiveX components seamlessly into the same application. The Java IDL interface, which will allow Java classes to operate with existing CORBA systems, is due out this year.
While the Beans/ActiveX bridge and Java IDL are not part of the standard JavaBeans distribution, they round out JavaBeans' capabilities as an industrial-strength, open technology for portable component software.
We've covered a lot of ground. In this article, you've learned what software components are and why they're valuable. You then learned about the various properties of JavaBeans, including properties, customization, events, introspection, persistence, packaging, and interoperation with legacy component systems.
In the next article in this series, we'll get you started using JavaBeans, and look at Bean properties in depth: how they work, and how to make your Beans customizable. As we go along, we'll discuss the new Java core features that make Beans possible. Future articles in this series will delve into the details of the topics we discussed this month.
Page 1 A walking tour of JavaBeans
Page 2 What JavaBeans is, and what it does
Page 3 Event handling
About the author
Mark Johnson has a BS in Computer and Electrical Engineering from Purdue University (1986). He has 15 years of experience programming in C and two years in C++, and is a fanatical devotee of the Design Pattern approach in object-oriented architecture, of software components in theory, and of JavaBeans in practice. Over the past several years, he worked for Kodak, Booz-Allen and Hamilton, and EDS in Mexico City, developing Oracle and Informix database applications for the Mexican Federal Electoral Institute and for Mexican Customs. He spent the last year working at NETdelivery, an Internet startup now in Boulder, CO. Mark is a dyed-in-the-wool Unix programmer, and sees Java as the missing link between the now ubiquitous desktop client systems and open, distributed, and scalable enterprise back-ends. He currently works as a designer and developer for Object Products in Fort Collins, CO.