Bean Introspection  «Prev  Next»
Lesson 2Peering inside a Bean
Objective How do JavaBeans expose their internal structure and functionality?

Peering Inside JavaBeans

Bean Introspection Services
One of the most critical requirements of JavaBeans is that it provide a way for Beans to expose information about themselves.
This is important because application builder tools and developers need to be able to take a prepackaged Bean and have a consistent and preferably automated way to find out how it works. The mechanism that exposes the structure and functionality of a Bean to the outside world is called introspection [1].
There are two ways that Beans support introspection.

Introspection and JavaBeans

Introspection is one of the key enhancements to Java provided by JavaBeans.
One of the major drawbacks to Java prior to JavaBeans was that standard Java objects could not be used in a dynamic runtime setting since there was no means of finding out about the structure or functionality of the objects at runtime. The introspection facility provided by JavaBeans exposes the structure and functionality of JavaBeans components. This support is an absolute necessity for allowing JavaBeans components to be used in application builder tools.

public class Introspector extends Object					 


The Introspector class provides a standard way for tools to learn about the properties, events, and methods supported by a target Java Bean. For each of those three kinds of information, the Introspector will separately analyze the bean's class and superclasses looking for either explicit or implicit information and use that information to build a BeanInfo object that comprehensively describes the target bean.
For each class "Foo", explicit information may be available if there exists a corresponding "FooBeanInfo" class that provides a non-null value when queried for the information. We first look for the BeanInfo class by taking the full package-qualified name of the target bean class and appending "BeanInfo" to form a new class name. If this fails, then we take the final classname component of this name, and look for that class in each of the packages specified in the BeanInfo package search path.
Thus for a class such as "sun.xyz.OurButton" we would first look for a BeanInfo class called "sun.xyz.OurButtonBeanInfo" and if that failed we'd look in each package in the BeanInfo search path for an OurButtonBeanInfo class. With the default search path, this would mean looking for "sun.beans.infos.OurButtonBeanInfo".
If a class provides explicit BeanInfo about itself then we add that to the BeanInfo information we obtained from analyzing any derived classes, but we regard the explicit information as being definitive for the current class and its base classes, and do not proceed any further up the superclass chain.
If we don't find explicit BeanInfo on a class, we use low-level reflection to study the methods of the class and apply standard design patterns to identify property accessors, event sources, or public methods. We then proceed to analyze the class's superclass and add in the information from it (and possibly on up the superclass chain).

  1. By conforming to JavaBeans design patterns
  2. By explicitly providing information about themselves

Definition of Introspection

In the next lesson, you learn how design patterns are used to provide automatic introspection capabilities.

The BeanInfo Interface

Introspection is a mechanism for providing information about a Bean explicitly. This is done by creating a class that exists specifically to describe the Bean. This class implements the java.beans.BeanInfo interface, which specifies a set of methods that can be used to gather various pieces of information about a Bean. The methods defined by this interface are shown in Table 5-2.

Table 5-2, Methods of the BeanInfo Interface
Table 5-2: Methods of the BeanInfo Interface


Reflection versus Introspection

Everything about our beans has been determined by low-level reflection, that is, by looking at the methods of our classes. The java.Beans.Introspector class gathers information on a bean using reflection, then analyzes and describes a bean to any tool that wants to know about it. The introspection process works only if the class follows the JavaBeans naming conventions for its methods; furthermore, it gives us little control over exactly what properties and events appear in NetBeans menus.
For example, we have seen that NetBeans by default shows all the stuff we inherit from the base Swing component. We can change that by creating BeanInfo classes for our beans. A BeanInfo class provides the JavaBeans introspector with explicit information about the properties, methods, and events of a bean; we can even use it to customize the text that appears in menus in NetBeans (and in other IDEs). A BeanInfo class implements the BeanInfo interface. That is a complicated proposition; in most situations, the introspector's default behavior is reasonable. Instead of implementing the BeanInfo interface, we extend the SimpleBeanInfo class, which implements all of BeanInfo's methods. We can override specific methods to provide the information we want; when we do not override a method, we will get the introspector's default behavior.

[1]Introspection: the mechanism that exposes the structure and functionality of a Bean to the outside world.