Let's talk about exceptions ...
How do you handle exceptions? Do you think upfront about the type of exceptions that you want to catch or do you just let the outside world handle it?

-- Jeroen van Bergen in JW Blogs

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com > Java Standard Edition >

Make a sweep with clean beans

Design rules that will keep your beans clean and your apps secure

By Philippe Kaplan, JavaWorld.com, 11/20/99

Classes are basic structures in an object-oriented language such as Java. Apart from syntactic and type constraints, there are no limitations as to what is a valid class and what is not. However, a class can be reused, via subclassing, and automatically processed by an application that dynamically imports objects. For these uses, the general class definition is too weak and must be refined.

Let there be beans

Beans were developed to meet this shortcoming. Upon automatic processing, beans present a predictable interface by setting more constraints on classes. If you reuse a class, you should also work with beans, because they are cleaner than general classes.

At a minimum, a bean must be serializable, and be a public class with a public zero-argument constructor. Other, optional, characteristics that improve a bean's interoperability are the ability export values, called properties, via accessors (get/set methods), and the ability to notify listeners using an event model (like AWT 1.1).

The introspection mechanism figures out a bean's events and properties according to the signature of its accessors, such as the pattern by which these methods access the events and properties. For example, the two methods String getFoo() and void setFoo(String arg) identify a string property named foo.

The bean package also specifies the BeanInfo class that describes the bean class. BeanInfo assists the code introspector while the bean is dynamically processed.

Beans define a component framework and are quite autonomous. The autonomy of a bean makes reuse and automatic processing easier, because the constraints on a bean and on its properties require that its interface be more predictable than a general class. A bean is created using the zero-argument constructor, and is customized by invoking the setter methods. Without the bean's constraints, you have to choose between the available constructors to create an instance, and find the right methods to call among all the methods provided by the class. However, even having these constraints in place is still not enough for true interoperability.

Take applets, for example. They run safely inside a browser because security constraints prevent them from damaging their hosts and user environments. In contrast, there is no such security model for beans that maintains their behavior. If a bean acts poorly, it endangers the applications that integrate it. Integrating a component safely into a program is a long-standing problem in software development. Beans do not solve it, but they can help.

Rules for clean beans

In this article, I would like to propose the concept of the clean bean, a bean which meets a minimum quality level, and which can thus be integrated and used safely in a dynamic environment.

Figure 1. Class types

Figure 1 presents the different class types. Only some classes can be considered beans, and only some beans merit the clean label. The following are the requirements that a bean must fulfill in order to be considered clean:

  1. The clean bean state is entirely defined by its properties.

  2. Accessors are independent. In particular, accessor calls are commutative.

  3. Clean bean property values are either themselves clean beans, or associated with a java.beans.PropertyEditor (note that primitive values have PropertyEditor already built in).

  4. Event listeners must be exported as indexed properties.

  5. Clean beans are error proof.

  6. Clean beans are thread safe.


With this set of constraints, an application can trust the clean bean and use it without risking a drop in quality. Let's examine these clean bean requirements in detail.

1. The clean bean state is entirely defined by its properties

This constraint is essential. A clean bean cannot afford to have a hidden state that leads to differing behavior in identical usage situations.

Note that a bean's internal variables are compatible with this rule. The rule says that the bean state depends only on the property values. If the bean manages an internal state that is not related to the properties, then this state has no importance for the bean, though it may be used by the bean to double-check, to optimize, to cache, and so forth.

2. Accessors are independent

This rule generally states that a clean bean does not assume a standard policy for calling its accessors. In particular, there is no policy on how multiple accessors are invoked. For instance, accessor calls are commutative -- that is, there is no particular order in which they must be invoked.

Another good example is the synchronized call of several accessors. If the bean requires several accessors to be called in the same thread in order to work properly, then the properties are in some way dependent, revealing a design flaw somewhere.

Instead of dependent accessors, a better design pushes the dependence inside the value (gathering the dependent properties into one property, for example) using a suitable data structure as the value type. This data structure encapsulates the implicit dependence of the previous properties, taking advantage of the type-checking for good data use.

The independence of accessors improves security, because it suppresses hidden constraints that only appear in the documentation (e.g., "Remember to call setXXX() before setYYY(), or it will not work"). As a result, the rule saves you the difficulty of asserting such a constraint in the code.

3. Property values are closed

This rule is also essential, because it implies that a clean bean stays in a world of clean beans. If a property value is not itself a clean bean, it must be precisely described by a java.beans.PropertyEditor (see the bean documentation for details on PropertyEditor). This ensures that a bean box that manipulates a clean bean can offer a workable user interface for bean customization, one that works with all values.

Clean beans work recursively, and PropertyEditor provides a means (usually through string converters) to edit the property value. Other values must be processed as special cases, therefore, the blind exploration of a bean is defeated, and the user can take advantage of true interoperability.

Resources