In order for a bean to be used by a builder tool, the builder tool must be able to learn about the bean. At runtime also, we need to be able to find out which properties, methods, and events a bean supports. This process is called introspection.
One of the goals of the JavaBeans architecture is to make it easy to write simple beans, and it does this by providing default implementations for most common tasks. For introspection, the idea is to not require the developer to do a lot of extra work just to support it. On the other hand, for more complex components, it is necessary that the component developer have full control over which properties, methods and events are exposed.
Therefore, JavaBeans provides a composite mechanism for supporting introspection.
- By default, a low-level reflection mechanism is used to determine which methods are supported by a target bean, and then design patterns are applied to deduce which properties, events and public methods are supported.
- Alternately, a bean developer can choose to provide a BeanInfo class to describe their bean, and this BeanInfo class will then be used to discover the bean's behavior.
These two mechanisms are not completely independent, but actually work in conjunction with one another to analyze a bean.
By design patterns we mean conventional names and type signatures for sets of methods and/or interfaces that are used for standard purposes. This meaning for design patterns is illustrated in an example below.
These design patterns have two uses.
- They provide a useful documentation hint for human programmers.
- Tools can be written to recognize design patterns, which can then be used to analyze and understand components.
This example design pattern is for simple properties. By default, we use design patterns to locate properties by looking for methods of this form:
public <PropertyType> get<PropertyName>(); public void set<PropertyName> (<PropertyType> a);
If we discover a matching pair of " get<PropertyName> " and "set<PropertyName>" methods that take and return the same type, then we regard these methods as defining a read-write property whose name will be "<PropertyName>". We will use the "get<PropertyName>" method to get the property value and the "set<PropertyName>" method to set the property value.
If we find only one of these methods, then we regard it as defining either a read-only or a write-only property called "<PropertyName>".
So a simple read-write property "foo" might be represented by this pair of methods:
public Hoohah getFoo(); public void setFoo(Hoohah a);
The design patterns used to analyze beans include design patterns for properties (simple, boolean, indexed), design patterns for events (multicast, unicast), and design patterns for methods. Several of the references cited on the main page contain more detailed information about design patterns used during introspection.
top
For a single bean, both explicit specification of its properties and implicit analysis are allowed. To simplify access to this information, and to make sure that all tools apply the same analysis rules, the java.beans.Introspector class is provided. To obtain a complete picture of a bean, application tools should always use the Introspector interface. The .getBeanInfo method of the Introspector class returns an instance of BeanInfo which it "constructs" as described in the next paragraph.
The Introspector class walks over the class/superclass chain of the target class. It checks at each level to see if there is a matching BeanInfo class; if there is one, it uses the explicit information provided. Otherwise it uses the reflection APIs to study the target class, and uses design patterns to analyze its behavior. The Introspector class then proceeds to continue its introspection.
The developer of the bean, then, has two choices regarding support for introspection. If she is creating a simple bean, she only needs to make sure she has followed the design patterns when declaring properties, etc. in her code. And if she is creating a more complex bean, she may choose instead to create a BeanInfo class to accompany her bean, in order to have greater control over the exposed elements.
top