Javabean Introspection Services

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.