Introduction

This guideline focuses on designing JavaBeans and different choices a designer can make.

For more information on JavaBeans, see Concept: JavaBean.

JavaBean Properties

Internally, a property value can be stored as a private field, but it can be calculated as well. The designer has a choice of pre-computing the value of the property, or use lazy evaluation, where the value will be calculated only when asked for by a caller.

The designer also has a choice of bounding or constraining the property. If the property is bound or constrained, then the designer must decide on the events and notification mechanism.

Events and Notification

For the implementation of the notification mechanism, the designer has two choices:

• Use PropertyChangeSupport and PropertyChangeEvent classes from the java.beans package.
• Create a custom notification mechanism

Classes from the java.beans package provide implementation that is applicable in most situations. PropertyChangeEvent contains the reference to the object that fired the event, the name of the property as String, and two objects representing the old and the new value of the property. Class PropertyChangeSupport maintains a collection of PropertyChangeListeners and contains the code for the notification in the method firePropertyChange.

PropertyChangeSupport is commonly used for JavaBeans that make up part of the user interfaces.

Custom notification may be appropriate where the overhead of the creation of event objects needs to be minimized. The downside is that the implementer must implement the notification mechanism. The implementer of the custom notification must keep in mind that a different thread may add or remove listeners during the notification process. In order to provide for the correct behavior, most solutions create a copy of the collection that holds the listeners; the notification is then performed using the copy. Most published implementations create such a copy at the beginning of the notification process, which results in the creation of many clones and degraded performance. However, since notifications are more common than listener additions or removals, a longer-lived copy can be created in advance during the addition or removal of the listeners and then reused for notifications, providing for faster execution.

Considering productivity of developers, custom notification should be attempted only when the performance of property change support from the java.beans package proves to be the bottleneck.

The following examples demonstrate both the use of the property change support from the java.beans package, as well as the use of a custom notification mechanism.

Example: Tank JavaBean using java.beans.PropertyChangeSupport

Here we have a JavaBean representing a Tank, which has one bound property: level. When the level of the Tank is changed, the Tank fires a PropertyChangeEvent which is handled by the TankController object.

Example: Tank Java Bean using Custom Notification

In the following example, the class Tank is implemented with a custom, more efficient notification mechanism, which avoids creation of objects during the notification.