Create components in your application with JavaBeans

by Peter V. Mikhalenko | Dec 13, 2006 8:00:00 AM

Tags: Java, Middleware, Persistence, Peter V. Mikhalenko, bean, JavaBeans, Java Tips Newsletter

Takeaway: JavaBeans let you visually assemble components and dynamically change properties on the fly. Peter V. Mikhalenko discusses the JavaBeans conventions, events, and listeners.

The JavaBeans model enables developers to create software units called components (also known as beans). You can assemble beans into composite components, applets, or applications. JavaBeans, which are widely used in IDE applications, let you visually assemble components and dynamically change properties on the fly.

Get developer tips in your inbox

Delivered each Thursday, our free Java newsletter provides insight and hands-on tips you need to unlock the full potential of this programming language.

Automatically sign up today!

Beans are dynamic in that you can change or customize them. Through the design mode of a JavaBeans Builder Tool, you can use the bean's Properties window to customize the bean and then save (persist) your beans using visual manipulation. You can select a bean from the toolbox, drop it into a form, modify its appearance and behavior, define its interaction with other beans, and combine it and other beans into an applet, application, or a new bean.

Beans vary in functionality and purpose. For instance, you can use them for the following:

• Graphical user interfaces (GUIs)
• Non-visual beans, such as a spelling checker
• Other types, like applets

The JavaBeans conventions

A JavaBean is simply a Java class. The JavaBeans API specification defines an easy convention of methods and fields that you must use in a Java class in order for it to be a JavaBean. The bean's features (i.e., its properties, methods, and events) can be discovered by an application that needs to plug in the bean, or by an IDE application like IBM Eclipse or IntelliJ IDEA. The process of such discovering is called introspection.

Beans support introspection in the following two ways:

• They adhere to specific rules known as design patterns when naming bean features. The java.beans.Introspector class examines beans for these design patterns to discover bean features. The java.beans.Introspector class relies on the core reflection API.
• They explicitly provide property, method, and event information with a related bean information class that implements the BeanInfo interface. A BeanInfo class explicitly lists the bean features that are to be exposed to application builder tools.

Properties are the appearance and behavior characteristics of a bean that you can change at design time. Bean Builder tools introspect on a bean to discover its properties and expose those properties for manipulation. Beans expose properties so they can be customized at design time. Customization is supported in two ways: by using property editors or by using more sophisticated bean customizers.

Beans use events to communicate with other beans. A bean that receives events (a listener bean) registers with the bean that fires the event (a source bean). Bean Builder tools can examine a bean and determine which events that bean can fire (send) and which it can handle (receive).

Persistence enables beans to save and restore their state. After changing a bean's properties, you can save the state of the bean and restore that bean at a later time with the property changes intact. The JavaBeans architecture uses Java Object Serialization to support persistence. A bean's methods are no different from Java methods, and you can call them from other beans or a scripting environment. By default, all public methods are exported.

Here are four simple and required conventions that make it possible to turn a Java class into a JavaBean:

• The class should be serializable (able to persistently save and restore its state), i.e., it must implement the java.io.Serializable interface.
• It should have a no-argument constructor.
• Its properties should be accessed using get, set, and other methods following a standard naming convention: getProperty() and setProperty() for a non-Boolean property named Property, or isProperty() for a Boolean Property. These methods are called getters and setters.
• It should contain any required event handling methods.

Example

Listing A is an example of the simplest JavaBean. The major Java GUI toolkits (AWT, Swing, and SWT) use JavaBeans conventions for its components. This allows GUI editors like the Eclipse Visual Editor or any other Java IDE to maintain a hierarchy of components and to provide access to their properties via getters and setters.

JavaBeans events and listeners

An event set defines a type of event, including what it communicates and what is required to generate and to listen to the event. An event set consists of the following:

• The event listener interface
  The interface defines one or more methods that must be implemented by a class that wishes to receive an event of this type. The methods typically take one or more parameters, including the event object.
• An event object
  This is passed from the source to the listener. It contains all the necessary parameters that may interest a listener, including the origin of the event source. All events derive from java.util.EventObject.
• The event registration methods, add<Event>Listener() and remove<Event>Listener(), permit the component to manage all the components that register interest in this particular event. These methods take a single parameter—the object that is interested in listening for the event. By definition, the object must implement the <Event>Listener interface.

The java.awt package provides several predefined event sets, such as focus events, mouse events, mouse move events, key events, and so on. These event sets include both the <Event>Listener interfaces and the event objects.

For instance, consider the key events. The key events set includes the KeyListener interface (which defines the keyPressed(), keyReleased(), and keyTyped() methods) and the KeyEvent class. Any component that generates key events must define the addKeyListener() and removeKeyListener() registration methods. Note the naming pattern convention for key events: The event name Key appears in the listener interface, its methods (optional), the event object, and the registration methods. You should use this same naming pattern for all the event sets you create.

The predefined event sets (such as the key events set) are usually sufficient for your programming needs. However, you can create your own event sets if you choose.

If you want a component to generate events, you must define the event set, the event object, and the event registration methods so that other components that register interest in the event can be notified of the event firing.

Peter V. Mikhalenko is a Sun certified professional who works for Deutsche Bank as a business consultant.