Bean Introspection  «Prev  Next»
Lesson 1

Introduction to Java Beans Introspection

Deeper inside a Bean

How does introspection expose the internals of JavaBeans?

This module continues with the study of Bean structure by examining introspection and how Beans expose information about themselves.
You learn about the two different approaches to introspection supported by JavaBeans: automatically using design patterns or explicitly using a special class in the JavaBeans API.
The module culminates in the complete development of a basic Bean, which draws upon much of what you have learned throughout the entire course thus far.

Module learning objectives

After completing the module, you will have the knowledge and skills necessary to:
  1. Apply property and event design patterns to support automatic introspection
  2. Explicitly provide Bean information in lieu of automatic introspection
  3. Build a basic Bean from scratch
In the next lesson, you learn how Beans expose their internal structure and functionality.

What is Introspection?

  1. Introspection is the automatic process of analyzing a bean's design patterns to reveal the bean's properties, events, and methods
    This process controls the publishing and discovery of bean operations and properties
  2. By default, introspection is supported by reflection, where you name methods with certain naming patterns, like set/getProperty() and
    add/removeListener()
    

Developing Java Beans
When Beans are used by a visual development tool, they have to expose their properties, methods, and events. This allows both the tool and the user to manipulate the Bean's appearance and behavior. We have already seen this when we used BeanBox to work with the simulator Beans: BeanBox allowed us to change property values for the Beans, and to connect event sources with event targets. We didn not have to write any extra code to tell BeanBox about the Bean's properties and events. Instead, it relied on the Java reflection mechanism to gather this information. We have actually been providing all of the necessary information all along by following the design patterns for properties and events when we wrote the code for the Beans. For instance, all of the Beans we have created so far have used 1) getPropertyName() and 2) setPropertyName() methods for their properties. Remember that this is the pattern for coding a read/write property. Using these patterns allows the Java reflection mechanism to analyze the code and determine that there is a property called PropertyName.
Sometimes the information that we provide implicitly using design patterns is not enough, and sometimes the reflection mechanism exposes more information than we want exposed. The reflection mechanism also forces us to follow design patterns that may not make sense all of the time. Finally, we sometimes want to expose information about our Beans that cannot be represented by the standard design patterns.

Quiz Question on JavaBeans

Which of the given statements are true, if a JavaBean has the string property name, on which reading and writing are allowed? (Choose two)
  1. The getter and setter methods must be public.
  2. For boolean properties, the setter method must always start with "is".
  3. The setter method must have the property type as the return type.
  4. The setter method must have the property type as the argument type.
  5. The getter method must have the property type as the argument type.


Answer: A, D
Choices A and D are the correct answers.
According to the JavaBeans naming standards, if the property name is 'x' and the type is Type, the accessor method is of the form:
public Type getX() 

and the mutator method is of the form:
public void setX(Type newValue) 
However, boolean property uses another convention as the following as well:
public boolean isX() 
public void setX(boolean newValue) 

For read/write properties, both getter and setter methods must be public, so choice A is correct.
Properties of boolean type may use getter methods starting with "get" or "is". So choice B is incorrect. The setter method must have the property type as the argument type, while the getter method must have the property type as the return type. Hence, choice D is correct, while choices C and E are incorrect.