Peering Inside JavaBeans

If you are new to component software, you might not fully understand the need for introspection services. In fact, introspection is probably the least understood aspect of the JavaBeans technology, simply because few developers have ever had to concern themselves with it. It is easy to take for granted the insight you have as a Java developer when you manually reuse a Java class in Java code. When you move into developing component software, however, you have to concern yourself with how a component is going to be used by others. More specifically, you have to address the problem of designing your components so that they can be reused in visual development environments. Introspection information is added to a component to document the services the component provides along with how the component functions.
Visual development environments study this introspection information to determine how to properly incorporate a component into their environment.

At runtime and in the builder environment we need to be able to figure out which properties, events, and methods a Java Bean supports. We call this process introspection. We want Java Beans developers to be able to work entirely in terms of Java. We therefore want to avoid using any separate specification language for defining the behaviour of a Java Bean. Rather we would like all of its behaviour to be specifiable in Java. A key goal of Java Beans is to make it very easy to write simple components and to provide default implementations for most common tasks. Therefore, we would like to be able to introspect on simple beans without requiring that the beans developer do a whole bunch of extra work to support introspection. However, for more sophisticated components we also want to allow the component developers full and precise control over which properties, events, and methods are exposed.
We therefore provide a composite mechanism. By default we will use a low level reflection mechanism to study the methods supported by a target bean and then apply simple design patterns to deduce from those methods what properties, events, and public methods are supported. However, if a bean implementor chooses to provide a BeanInfo class describing their bean then this BeanInfo class will be used to programmatically discover the beans behaviour. To allow application builders and other tools to analyze beans, we provide an Introspector class that understands the various design patterns and standard interfaces and provides a uniform way of introspecting on different beans. For any given bean instance we expect its introspection information to be immutable and not to vary in normal use. However if a bean is updated with a new improved set of class files, then of course its signatures may change.

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 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).

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

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.

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.