JavaBeans Bound Properties

This week we're going to look at another noteworthy feature of JavaBeans. If you're just starting with us, you can check out the past few issues to see where we got started on the topic.

This week we're focusing on Bound Properties. Last week, we introduced properties in general. Basically making a new piece of jargon for an old tradition, the Beans standard formalized the use of methods whose names begin with "get" and "set" for checking and changing information stored in objects. Anything referenced in this way is now considered a property, and a moderate portion of the JavaBeans technology consists of manipulating these properties (in a user-friendly GUI window, of course) to make Beans perform as desired.

Now come the frills. We discussed some last week, but we're about to begin explaining the important ones.

Bound properties cause something to happen when they change--a basic feature, but worth spending some time on nonetheless. In the BeanBox, for instance, you can connect the change of a property in one Bean to the execution of a method in another by selecting the propertyChange event from the Edit menu, selecting a target bean, and the method you want invoked within it.

The current model, remember, is based on being able to easily set up relationships between activity in one Bean and execution of code in others. Bound properties really only slightly extend the reach of this capability; it's a standard, in other words, for making an Event out of the change of a property. Let's look at how the API designers did it:

private PropertyChangeSupport pcs = new PropertyChangeSupport(this);

The standard works around a new object that you carry inside your Bean-- PropertyChangeSupport. It's designed to keep a list of other objects that want to be alerted when a change occurs (thought it can't do so without your help, as we'll see in a minute), and contains a method for doing so:

pcs.firePropertyChange("PropertyName",oldValue,newValue);

This line, inserted into the setPropertyName method in your Bean, actually calls the target methods in the "Listening" objects. Now, for the other half of the job, the following is needed in order for the property change system to keep track of who's listening:

public void addPropertyChangeListener(PropertyChangeListener x)
{
  pcs.addPropertyChangeListener(x);
}

public void removePropertyChangeListener(PropertyChangeListener x)
{
  pcs.removePropertyChangeListener(x);
}

Two exceedingly simple methods must be included in the Bean, which can be called by outside entities to register and unregister themselves with the system.

That's all, though for some that may be more than enough. For ourselves, after having suffered through some far worse programming environments, we're still gratified that this overhead is only required when we want to use it. Keep in mind, as always, that this is a standard; most all of the effort here is under the auspices of organization.

Close observers may note a certain stylistic strangeness about all of this. There's a reason for this seemingly cumbersome (although probably relatively simple) approach of creating special objects and requiring special methods: Beans were invented too long after Java, and their impact on the language itself must be kept to a severe minimum.

Just as Remote Method Invocation (which we've complained about in another issue) required developers to make leaps and bounds in coding to keep the Java standard intact, so does this--to an extent.

Let us reiterate the sometimes surprising fact about JavaBeans: It doesn't represent a change in the Java language at all, except in as much as it precipitated developments like reflection and serialization. It's merely guidelines from Sun about how to write in Java, with some helpful code included in the package.

Food for thought, at any rate. See you next week, when we'll tear the wrappers off of some more JavaBeans features.

Past installments of Java Jolt