by Rik Farrow
<rik@spirit.com>

Although I have tried to avoid it, I find myself writing about Java Beans. The migration to JDK version 1.1 brought many changes and new classes, among them Beans. I was at first overwhelmed by the amount of change in 1.1, as were some people I spoke with. But when I finally looked at Beans, I discovered they can actually be quite simple. In fact, a Button from the AWT could be used as a Bean or even a completely non-graphical class, like the following.

public class ABean implements java.io.Serializable {
 protected int aValue;
 public void setAValue(int value) {
   theValue = value;
 }
 public int getAValue() {
   return aValue;
 }
}

Not very exciting, but still a Bean. The Java Bean white paper describes a bean as a reusable software component that can be manipulated visually in a builder tool. I haven't (apparently) done anything special in the ABean class. Actually I have, and it relies on two aspects of Java, one new to 1.1 and both common in object design.

The first trick has to do with reflection ­ the ability of a programming language to examine itself. The java.lang.reflect package includes classes that permit Java code to explore the structure of a class (under limits imposed by the security manager). Because each class includes all the information needed to be dynamically loaded and used, this should not be too surprising ­ you can think of it as a type of object debugger. But instead of just debugging, the reflect package lets you list the variables, methods, and constructors of a class. Reflection is also used in Java serialization, the technique used to create persistent Java objects.

The Introspector class, included with the Beans class library, uses reflection to extract information from a Java Beans class. You don't have to write this class, and every tool vendor can use the same class to analyze a Bean.

What the Introspector abstracts from a Bean relies on design patterns, the second aspect I alluded to. Methods beginning with set (and returning void) and get are extracted, the get/set deleted, and the remainder of the Method name represents a property of the Bean. In my trivial example, the only property is AValue. Properties can be read-only (only a get method) or even write-only. The 1.1 AWT components are all written using this design pattern, so the foreground and background colors and font are properties of these components. (Events are also extracted, but more on that later.)

You can ignore these patterns if you wish by building a companion class that implements BeanInfo. The BeanInfo class is separate from the Bean itself. It is used while manipulating the Bean but is not required in a finished application, when it would just be additional baggage.

Bean Box

A better way to get a handle on Beans is to download the BDK, the Bean Developer's Kit (<java.sun.com/beans/software>). You will need a 1.1 version of the JDK (I used JDK 1.1.4, which differs from 1.1 in that it includes various bug fixes). At this time, only the HotJava browser fully supports 1.1, which means that even if you create Bean applets, you can view them only with HotJava or the 1.1 appletviewer. There is also a short tutorial that guides you through using the Bean Box, a simple visual developer tool.

Part of what's neat about the Bean Box is that although it is a bare-bones tool, most of the functionality is included in the Beans library. Starting up the Bean Box produces three windows, a palette, an empty container where you can drop the Beans, and a property window. The container window includes a menu bar, so please don't be surprised when I mention a File menu.

You add Beans to the container by clicking on one in the palette, then picking the center of the component in the container and clicking again. This action selects the new Bean and converts the third window into a display of the editable properties of the Bean. For example, if you choose the first Bean, OrangeButton, four properties will be displayed: foreground color, label, background color, and font. Clicking on the color properties brings up a color selection window, and clicking on the font lets you pick a font.

The properties windows is part of a built-in class that any Beans development tool can use. If you build a Bean with properties that are more complex than can be handled with a simple properties editor, you can build customized property editors and step your developers through the process of editing the properties.

Events

Now you have a customizable OrangeButton, but what can you do with it? Well, suppose you have been experimenting with the other beans and have placed a JugglerBean into your container. The JugglerBean begins juggling, which can be quite annoying. You can slow down the juggler by increasing its delay property, but you can't stop it. But there is a way, which illustrates another important aspect of Java Beans.

Select the OrangeButton, then open the Edit menu (next to File in the menubar), and select Events, button push, actionPerformed. You have now chosen to add a component as the target of this event, and a red line will follow your cursor until you click on another component. Pick the juggler.

Ah. Now a new window appears (the Event Target Dialog), which permits you to select an event listener method on the juggler. Select stopJuggling. The window changes to a message that reports that a new adaptor class is being generated. Once the window disappears, click on the OrangeButton and the juggler will stop.

You use events to communicate between Beans. You can have invisible Beans, like the TickTock, which comes with the Bean Box and fires off TimerEvents. You can create your own invisible Beans, which can listen for events or property changes and fire off events in return.

You can customize the Bean Box by creating your own Beans, writing a manifest, collecting the Beans into a jar file, and loading this jar file using the File menu in the Bean Box's container window. And if you really like what you have accomplished, you can save the container, along with its customized Beans, by serializing them (saving them as a file).

This column is no more than a basic introduction to Java Beans, just to provide a few of the capabilities. In subsequent columns, I plan on presenting example Beans that can be used in the Bean Box and will actually do something (other than juggle). If you can't wait, O'Reilly's Exploring Java (Patrick Niemeyer and Joshua Peck) has a chapter on Beans that is sufficient to get you going, and their Developing Java Beans (Rob Englander) goes into 300 pages of excellent details.