CS102: Java Beans

Last time, we talked about reflection, the support JAVA provides for examining type information at run time. Given an object or class name, you can use the class Class to discover:

the fields of the class
constructors
methods
other properties (class name, isPrimitive etc.)

The next logical question is: Why would you ever want to write a program that does this? It seems like if there's information you need, why not look it up when you write the program? Why wait until run time?

Well, it turns out that there are applications that benefit tremendously from being able to examine the type of an object at runtime.

A typical example of this is a builder tool that lets you

graphically assemble the components of a user interface
edit the properties of components
specify how information in a component is to be propagated to other components

In order to accomplish this, the builder tool must know about the properties of the components and be able to provide the user with a way to edit them. There are several approaches to this:

Allow the builder to manipulate only those components that are provided with the builder. Then all of the relevant info is known at compile time. But: then the system is not extensible - no new components can be added.

Requre that the programmer who creates a component also provide auxiliary information (such as property information and property editors) so that as new components are added, the tool knows how to use them. But: this puts a burden on the component designer.

Determine all the relevant information by letting the builder tool examine the type information of the components at run time. But: doesn't give the component implementer as much flexibility in controlling how the component is edited.

The Java Beans approach is a hybrid of approaches 2 and 3 above. Reflection is used to gain information about components, but the component implementer is allowed to specify more information.

What is Java Bean?

There's not a class or interface in Java called Bean. Basically, any class can be a bean - you just make it available to a builder tool and the tool figures out what it can do about the class in order to visually manipulate it and edit its properties.

However, by adhering to certain conventions in writing the code for a Java bean, the programmer can help the builder tool discover useful information. In addition, the programmer can specify more information explicitly by providing BeanInfo, PropertyEditor, and Customizer classes.

What is a Builder Tool?

Let's look at what a typical builder tool does with beans: Sun provides the beanbox, which is a reference implementation for builder tools.

Dragging from the palette to the form causes the constructor with no parameters to be called and causes the beanbox to get all the info on the bean. You can then edit properties and specify that a value of one property should be "connected to" another property of another bean. To react to events, you need to write the event handlers yourself.

In addition to the information a builder tool can discover from the bean's class definition through reflection, you can provide it with explicit additional information.

If your bean is called XXX, you can write a class called:

class XXXBeanInfo extends SimpleBeanInfo {
:
:
with methods:
getBeanDescriptor() // has class and customizer
getIcon() // for displaying the bean in the palette
getMethodDescriptors() // for providing more information than
getPropertyDescriptors() // can be gained through reflection alone

A property descriptor can provide a property editor, in case you don't want to use the standard property editor for that property type (or there isn't one available)

In addition, you can provide a customizer in the bean descriptor, for editing properties of the bean as a whole.