JavaBeans: Constrained Properties

This week we're getting closer to the end of our series of discussions about the basic features of JavaBeans.

Last week we talked about Bound Properties, that is, values kept within the JavaBean that cause things to happen when they're changed.

This week we'll talk about the next logical step (in both usefulness and complexity) within the framework: Constrained Properties.

Recall that Bound Properties were really only an extension of the general system for allowing events occurring in one Bean to regularly set off actions in another--in other words, a way of making the change of a property into an event. Constrained properties go one better. A constrained property not only starts other methods when it's changed, but allows for the methods it starts to stop the change.

There are potential needs for objects to exercise veto power over changes to a bean's properties--some simple (error checking on the property value), and some complicated (perhaps a large group of Beans engaged in complicated, interdependent behavior). In any case, remember to put this in a larger perspective. Sun is attempting to get Java developers to write objects that can be interconnected with each other easily, in standard ways, and this is an easily "standardizable" interaction between two objects.

It's accomplished with a trick almost exactly like what made bound properties work. There's a "utility" object that you must write into your Bean:

private VetoableChangeSupport vcs = new
VetoableChangeSupport(this);

Very much like last week's PropertyChangeSupport, to make it work there needs to be two methods in your Bean that allow "Listeners" to register themselves to receive vetoable change events ( see the last issue for an example). JavaSoft engineers call these methods multicast event registration listener methods.

We hate five-word names for things, and don't expect you to like them either. You can begin to decrypt this one (if you haven't already) by knowing that software engineers' general usage of the words "multicast" or "unicast" is partially related (not from the notion that cast refers to a variable type or class demarcation) to the word broadcast. That makes multicast a "clever" abuse of the word, which refers to the transmission of messages to several receivers; it pops up in networking as well as in event processing terminology.

There are two pressing differences between the system for change notification and the system for vetoable changes; the first is just a little bit subtle, and the second isn't:

public void setMyProperty (int newValue)
    throws PropertyVetoException
{
   vcs.fireVetoableChange("MyProperty",MyPropertyValue,newValue);

   MyPropertyValue = newValue;
}

The first and obvious change is that now our previously simple and unassuming "set" method throws an exception. (We talked about exceptions in a previous issue.) It turns out that this scheme is based on exceptions. A method "listening" to a vetoable change throws an exception to veto it.

The second thing to notice is that, unlike with a regular PropertyChange, we have to fire our VetoableChange before we change the actual value internal to our Bean (MyPropertyValue, in this case). You probably don't have to think too hard to figure out why; if the exception is thrown, then we don't want to have to take an extra step to change our internal value back to its original state.

What you don't see here that prevents us from having to do anymore work is the inside of fireVetoableChange; this method catches veto exceptions and prevents the change by setting the new value equal to the original one, if necessary.

Once again we call it relatively simple--that's good enough for us.

Coming up, we'll have coverage of Netscape Communicator Preview Release 4, the newly released Glasgow specifications for JavaBeans, and more on the Beans themselves.

Past installments of Java Jolt