JavaBeans Properties

For the past few weeks we've been looking at JavaBeans.

Last week we talked about the minimum requirements for making them; for those who skipped it, we basically concluded that every class is potentially a Bean, frills notwithstanding. This week we'll conduct a brief survey of the more advanced features of the Beans API that you can make use of if you decide to join the component software craze.

A lot of people new to components may look at the standard and ask, "What exactly do we mean by 'features'"? Let us explain. This new thrust in authoring is centered around not only how objects we write behave when we deploy them in our programs, but also how they behave in development environments as well. The "new thinking" here is that it's at least as important to be able to develop your application efficiently as it is to use it efficiently, even if it means the final product isn't quite as lean (and we'll talk about just how much so later).

Notice, this thinking underlies a lot of the features of Java; the JVM checks to make sure you don't write past the end of an array, for instance, which in classical thinking takes too much extra CPU time. From a modern standpoint, it seems we end up with a lot less of a headache when we don't have to worry about what happens when people overflow our buffers, even for the price of a slight speed hit.

Properties

You'll recall that in object-oriented programming we're fond of making methods for getting and setting various traits about our objects. JavaBeans, with laudable simplicity, formalizes this practice with Properties.

Properties are more or less what they sound like; in the BeanBox, just as (we assume) in the commercially available development systems, selecting a Bean brings up its Property Sheet--a list of modifiable traits associated with the object--which may be as simple as its color and its name. Or we can imagine that a clock Bean might have a property allowing one to set it to "analog" or "digital," or an animator Bean might have properties allowing us to configure what images make up the animation.

does your object have its getX and setX methods written properly? Surprise, you've already created your property sheet. Applications that follow the standard for handling JavaBeans will use introspection to look for appropriately named methods and include them in the properties sheet. The Java API, for instance, is already written this way, and so a lot of the built-in parts of your objects (like the label of a button, for instance) will already be there.

A getX without a setX, for instance, would make X a read-only property. A method isX indicates that X is either true or false. And if you're dealing with arrays of values, and you write a pair of get and set methods to set the whole array, and another pair (with the same names) allowing a specific element in the array to be set, like so...

public void setMyProperty (int index,int x)
{
  MyArray[index] = x;
}

you'd have what JavaBeans calls an Indexed Property. There are presumably special provisions made for it (in the interface allowing you to get or set it, of course) in the development systems.

Lastly (and most importantly), there are what we call Bound and Constrained properties. This is where the Beans system shows real promise of capability. Basically, by writing some special methods into your Beans, you can create properties that notify other objects in your application when they change and, moreover, give these objects a chance to act on (in some cases, to veto) it.

This is where things get just a little more complicated, and we'll tackle this issue in upcoming weeks. Stay tuned.

Past installments of Java Jolt