Previous | Next | Trail Map | JavaBeans Tutorial | Table of Contents


Writing Advanced Beans

This section contains lessons that illustrate more complex bean capabilities.


Previous | Next | Trail Map | JavaBeans Tutorial | Table of Contents
Previous | Next | Trail Map | JavaBeans Tutorial | Writing Advanced Beans


Implementing Bound Properties


Here is a list of background reading to prepare you for learning bound properties:

The Beans API provides an event mechanism for alerting listeners when Bean properties change. Listeners can be other objects, Beans, components, applications, applets or scripting environments.

There are three parts to a bound property implementation:

There is nothing new here; these are just specific interfaces and classes based on the AWT1.1 event mechanism.

Listeners must implement the PropertyChangeListener interface. Implementing this interface means that

Beans that are the source of property change events must maintain a PropertyChangeListener list, and fire events at each object in that list when a bound property changes. The utility class PropertyChangeSupport implements this functionality. Your Bean can inherit from this class, or use it as an inner class, as you will see.

The PropertyChangeEvent class encapsulates property change information, and is sent from the property change event source to each object in the property change listener list.

Implementing Bound Property Support Within a Source Bean

A Bean containing bound properties must

The java.beans package provides a utility class, named PropertyChangeSupport, which implements two methods that add and remove PropertyChangeListener objects to a listener list, and a method that fires property change events at each listener in that list when a bound property changes. Your Bean can either inherit from PropertyChangeSupport, or use it as an inner class.

To give your source Bean the ability to broadcast property changes events, take the following steps:

  1. Import the java.beans package. This gives you access to the PropertyChangeSupport class.

  2. Instantiate a PropertyChangeSupport object:
       private PropertyChangeSupport changes = new PropertyChangeSupport(this);
       
    This object manages the registered listener list, and property change event notification broadcast.

  3. Implement methods to maintain the property change listener list. Since we instantiated a PropertyChangeSupport object in this example (rather inheriting from it), these methods merely wrap calls to the property-change support object's methods:
        public void addPropertyChangeListener(PropertyChangeListener l) {
            changes.addPropertyChangeListener(l);
           }
        public void removePropertyChangeListener(PropertyChangeListener l) {
            changes.removePropertyChangeListener(l);
           }
      
  4. Modify a property's setter method to fire a property change event when the property is changed. OurButton's setLabel() method looks like this:
        public void setLabel(String newLabel) {
            String oldLabel = label;
            label = newLabel;
            sizeToFit();
            changes.firePropertyChange("label", oldLabel, newLabel);
          }
      

    Note that setLabel() stores the old label value, because both the old and new labels must be passed to firePropertyChange().

      public void firePropertyChange(String propertyName,
                                     Object oldValue, Object newValue)
      

    These values are then bundled into the PropertyChangeEvent object sent to each registered listener. The old and new values are treated as Object values, so if they are primitive types such as int, you must use the object version such as java.lang.Integer. Also note that the property change events are fired after the property has changed.

When the BeanBox recognizes the design patterns for bound properties within your Bean, you will see a propertyChange interface item when you pull down the Edit|Events menu.

Now that you have given your Bean the ability to broadcast events when a bound property has changed, the next step is to create a listener.

Implementing Bound Property Listeners

To listen for property change events, your listener Bean must implement the PropertyChangeListener interface. This interface contains one method:

   public abstract void propertyChange(PropertyChangeEvent evt)
Implementing the PropertyChangeListener interface in your class means implementing propertyChange().

So to make your class able to listen and respond to property change events, you must

  1. Implement the PropertyChangeListener interface.
          public class MyClass implements java.beans.PropertyChangeListener,
                                                       java.io.Serializable { 
          
    This interface contains one method, propertyChange(). This is the method that the property change event source calls when one of its bound propertys changes.

  2. Implement the propertyChange() method in the listener. This method needs to contain the code that handles what you need to do when the listener receives property change event. Very often this is a call to a setter method in the listener class: a property change in the source bean propagates a change to a property in the listener.

To register interest in receiving notification about a Bean property change, call the listener registration method on the source Bean. For example:

button.addPropertyChangeListener(aButtonListener);
Or, you can use an adapter class to catch the property change event, and subsequently call the correct method within the listener object. Here is an example taken from comments in the beans/demo/sunw/demo/misc/ChangeReporter.java file.
OurButton button = new OurButton();
...
PropertyChangeAdapter adapter = new PropertyChangeAdapter();
...
button.addPropertyChangeListener(adapter);
...
class PropertyChangeAdapter implements PropertyChangeListener
{
  public void propertyChange(PropertyChangeEvent e)
  {
    reporter.reportChange(e);
  }
}

Bound Properties in the BeanBox

The BeanBox handles bound properties by using an event hookup adapter class. The OurButton and ChangeReporter Beans can be used to illustrate this technique. To see how this works, take the following steps:

  1. Drop OurButton and ChangeReporter instances on the BeanBox.
  2. Select the OurButton instance and choose the Edit|Events|propertyChange|propertyChange menu item.
  3. Connect the rubber band line to the ChangeReporter instance. The EventTargetDialog will be displayed.
  4. Choose reportChange from the EventTargetDialog. The event hookup adapter source will be generated and compiled
  5. Select OurButton and change some of it's properties. You will see change reports in ChangeReporter.

Behind the scenes the BeanBox generated the event hookup adapter. This adapter implements the PropertyChangeListener interface, and also generates a propertyChange() method implementation that calls the ChangeReporter.reportChange() method. Here's the generated adapter source code:

// Automatically generated event hookup file.

package tmp.sunw.beanbox;
import sunw.demo.misc.ChangeReporter;
import java.beans.PropertyChangeListener;
import java.beans.PropertyChangeEvent;

public class ___Hookup_14636f1560 implements
            java.beans.PropertyChangeListener, java.io.Serializable {

    public void setTarget(sunw.demo.misc.ChangeReporter t) {
        target = t;
    }

    public void propertyChange(java.beans.PropertyChangeEvent arg0) {
        target.reportChange(arg0);
    }

    private sunw.demo.misc.ChangeReporter target;
}

The ChangeReporter Bean need not implement the PropertyChangeListener interface; instead, the BeanBox generated adapter class implements PropertyChangeListener, and the adapter's propertyChange() method calls the appropriate method in the target object (ChangeReporter).

The BeanBox puts the event adapter classes in the beans/beanbox/tmp/sunw/beanbox directory. When an adapter class is generated, you can view the adapter source in that directory.


Previous | Next | Trail Map | JavaBeans Tutorial | Writing Advanced Beans
Previous | Next | Trail Map | JavaBeans Tutorial | Writing Advanced Beans


Implementing Constrained Properties


To get the most out of this section, first read the following:

A Bean property is constrained when any change to that property can be vetoed. Usually an outside object exercises the right to veto, but the Bean itself can also veto a property change.

The Beans API provides an event mechanism, very similar to the bound property mechanism, that allows objects to veto a Bean's property changes.

There are three parts to constrained property implementations:

Implementing Constrained Property Support Within a Source Bean

A Bean containing constrained properties must

The VetoableChangeSupport utility class is provided to implement these capabilities. This class implements methods to add and remove VetoableChangeListener objects to a listener list, and a method that fires property change events at each listener in that list when a property change is proposed. This method will also catch any vetoes, and resend the property change event with the original property value. Your Bean can either inherit from VetoableChangeSupport, or use an instance of it.

Note that, in general, constrained properties should also be bound properties. When a constrained property change does occur, a PropertyChangeEvent can be sent via PropertyChangeListener.propertyChange() to signal all VetoableChangeListener Beans that the change has taken effect.

The JellyBean demo Bean has a constrained property. We will its code to illustrate the steps in implementing constrained properties. Here's the steps to implement constrained properties in your Beans:

  1. Import the java.beans package. This gives you access to the VetoableChangeSupport class.

  2. Instantiate a VetoableChangeSupport object within your Bean:
          private VetoableChangeSupport vetos = 
                    new VetoableChangeSupport(this); 
          
    VetoableChangeSupport manages a list of VetoableChangeListener objects, and fires property change events at each object in the list when a change occurs to a constrained property.

  3. Implement methods to maintain the property-change listener list. These merely wrap calls to the VetoableChangeSupport object's methods:
           public void addVetoableChangeListener(VetoableChangeListener l) {
            vetos.addVetoableChangeListener(l);
           }
           public void removeVetoableChangeListener(VetoableChangeListener l) {
            vetos.removeVetoableChangeListener(l);
           }
          
  4. Write a property's setter method to fire a property change event when the property is changed. This includes adding a throws clause to the setter method's signature. JellyBean's setPriceInCents() method looks like this:
          public void setPriceInCents(int newPriceInCents)
                                throws PropertyVetoException {
            int oldPriceInCents = ourPriceInCents;
    
            // First tell the vetoers about the change.  If anyone objects, we
            // don't catch the exception but just let if pass on to our caller.
            vetos.fireVetoableChange("priceInCents",
                                    new Integer(oldPriceInCents),
                                    new Integer(newPriceInCents));
            // No-one vetoed, so go ahead and make the change.
            ourPriceInCents = newPriceInCents;
            changes.firePropertyChange("priceInCents",
                                    new Integer(oldPriceInCents),
                                    new Integer(newPriceInCents));
          }
          

    Note that setPriceInCents() stores the old price, because both the old and new prices must be passed to fireVetoableChange(). Also note that the primitive int prices are converted to Integer objects.

          public void fireVetoableChange(String propertyName, 
                                        Object oldValue,
                                        Object newValue)
                                 throws PropertyVetoException
          

    These values are then bundled into a PropertyChangeEvent object sent to each listener. The old and new values are treated as Object values, so if they are primitive types such as int, you must use the object version such as java.lang.Integer.

Now you need to implement a Bean that listens for constrained property changes.

Implementing Constrained Property Listeners

To listen for property change events, your listener Bean must implement the VetoableChangeListener interface. This interface contains one method:

void vetoableChange(PropertyChangeEvent evt)
                        throws PropertyVetoException;

So to make your class able to listen and respond to property change events, your listener class must

  1. Implement the VetoableChangeListener interface.

  2. Implement the vetoableChange() method. This is the method that will be called by the source Bean on each object in the listener list (maintained by the VetoableChangeSupport object). This is also the method that exercises veto power. A property change is vetoed by throwing the PropertyVetoException.

Note that the VetoableChangeListener object is often an adapter class. The adapter class implements the VetoableChangeListener interface and the vetoableChange() method. This adapter is added to the constrained Bean's listener list, intercepts the vetoableChange() call, and calls the target Bean method that exercises veto power. You'll see an example of this in the next section.

Constrained Properties in the BeanBox

When the BeanBox recognizes the design patterns for constrained properties within your Bean, you will see a vetoableChange interface item when you pull down the Edit|Events menu.

As with any event hookup, the BeanBox generates an adapter class when you hook up a Bean with a constrained property to another Bean. To see how this works, take the following steps:

  1. Drop Voter and JellyBean instances into the BeanBox.
  2. Select the JellyBean instance, and choose the Edit|Events|vetoableChange|vetoableChange menu item.
  3. Connect the rubber band line to the Voter Bean. This brings up the EventTargetDialog panel.
  4. Choose the Voter Bean's vetoableChange method, and push the OK button. This generates an event adapter. You can view this adapter in the beans/beanbox/tmp/sunw/beanbox directory.
  5. Test the constrained property. Select the JellyBean and edit its priceInCents property in the Properties sheet. A PropertyVetoException is thrown, and an error dialog pops up.

Behind the scenes the BeanBox generated the event hookup adapter. This adapter implements the VetoableChangeListener interface, and also generates a vetoableChange() method implementation that calls the Voter.vetoableChange() method. Here's the generated adapter source code:

// Automatically generated event hookup file.

package tmp.sunw.beanbox;
import sunw.demo.misc.Voter;
import java.beans.VetoableChangeListener;
import java.beans.PropertyChangeEvent;

public class ___Hookup_1475dd3cb5 implements
        java.beans.VetoableChangeListener, java.io.Serializable {

    public void setTarget(sunw.demo.misc.Voter t) {
        target = t;
    }

    public void vetoableChange(java.beans.PropertyChangeEvent arg0)
                               throws java.beans.PropertyVeto Exception {
        target.vetoableChange(arg0);
    }

    private sunw.demo.misc.Voter target;
}

The Voter Bean need not implement the VetoableChangeListener interface; instead, the generated adapter class implements VetoableChangeListener. The adapter's vetoableChange() method calls the appropriate method in the target object (Voter).

Per Property Constraint

Like bound property support, there is design pattern support for adding and removing VetoableChangeListener objects that are tied to a specific named property:

 void addVetoableChangeListener(String propertyName,
                         VetoableChangeListener listener);
 void removeVetoableChangeListener(String propertyName,
                         VetoableChangeListener listener);
As an alternative, for each constrained property a Bean can provide methods with the following signature to register and unregister vetoable change listeners on a per property basis:
 void add<PropertyName>Listener(VetoableChangeListener p);
 void remove<PropertyName>Listener(VetoableChangeListener p);


Previous | Next | Trail Map | JavaBeans Tutorial | Writing Advanced Beans
Previous | Next | Trail Map | JavaBeans Tutorial | Writing Advanced Beans


Implementing Indexed Properties


To get the most out of this section, read the following documentation:


Indexed properties represent collections of values accessed, like an array, by index. The indexed property design patterns are

//Methods to access the entire indexed property array
public <PropertyType>[] get();
public void set<PropertyName>([] value);

//Methods to access individual values
public <PropertyType> get(int index);
public void set<PropertyName>(int index,  value);
Conforming to these patterns lets builder tools know that your Bean contains an indexed property.

The OurListBox demo Bean illustrates how to use an indexed property. OurListBox extends the List class to provide a Bean that presents the user a list of choices: Choices that you can provide and change at design time. Here's an illustration of an OurListBox instance:

OurListBox exposes the item indexed property with the following accessor methods:

public void setItems(String[] indexprop) {
  String[] oldValue=fieldIndexprop;
  fieldIndexprop=indexprop;
  populateListBox();
  support.firePropertyChange("items",oldValue, indexprop);
}

public void setItems(int index, String indexprop) {
  String[] oldValue=fieldIndexprop;
  fieldIndexprop[index]=indexprop;
  populateListBox();
  support.firePropertyChange("Items",oldValue, fieldIndexprop);
}
 
public String[] getItems() {
  return fieldIndexprop;
}
    
public String getItems(int index) {
  return getItems()[index];
}

When an item is set by one of the setItems() methods, OurListBox is populated with the contents of a String array.

Indexed properties are almost as easily exposed as simple properties. Writing an indexed property editor, though, requires writing a custom property editor.

Indexed Property Editors

The OurListBox demo Bean provides an associated IndexPropertyEditor which is a good example of how to implement an indexed property editor. The following illustration shows an OurListBox instance in the BeanBox, the Properties sheet which contains an entry for the indexed property items, and the IndexPropertyEditor which pops up when the items property entry is clicked:

Implementing IndexPropertyEditor is the same as implementing any custom property editor:

  1. Implement the PropertyEditor interface:
           public class IndexPropertyEditor extends Panel
                         implements PropertyEditor, Action Listener {
          
    You can use the PropertyEditorSupport class, either by subclassing or as an inner class.
  2. Denote the custom editor in a related BeanInfo class. OurListBox has a related OurListBoxBeanInfo class that contains the following code:
             itemsprop.setPropertyEditorClass(IndexPropertyEditor.class);
          

  3. Make the property editor a source for bound property events. The property editor will register property listeners, and fire property change events at those listeners. This is how the property changes are propagated back to the Bean (via the property sheet). So IndexPropertyEditor instantiates an inner PropertyChangeSupport class:
              private PropertyChangeSupport support =
                   new PropertyChangeSupport(this);
           
    Provides the ability for objects to register their interest in being notified when a property is edited:
           public void addPropertyChangeListener(PropertyChangeListener l) {
            support.addPropertyChangeListener(l);
           }
    
           public void removePropertyChangeListener(PropertyChangeListener l) {
            support.removePropertyChangeListener(l);
           }
           
    And fires property change events at those listeners:
              public void actionPerformed(ActionEvent evt) {
            if (evt.getSource() == addButton) {
                listBox.addItem(textBox.getText());
                textBox.setText("");
                support.firePropertyChange("", null, null);
            }
            else if (evt.getSource()== textBox) {
                listBox.addItem(textBox.getText());
                textBox.setText("");
                support.firePropertyChange("",null,null);
            }
            ...
           }
           

IndexPropertyEditor maintains listbox as a proxy for OurListBox. When a change is made to listbox, a property change event is fired to all listeners.

When the Properties sheet, which is registered as an IndexPropertyEditor listener, receives a property change event from IndexPropertyEditor, the Properties sheet calls IndexPropertyEditor.getValue() to retrieve the new or changed items and update the Bean.


Previous | Next | Trail Map | JavaBeans Tutorial | Writing Advanced Beans
Previous | Next | Trail Map | JavaBeans Tutorial | Writing Advanced Beans


Customizing Beans


To prepare yourself for learing about property editors and customizers, read the following documentation:

A Bean's appearance and behavior can be customized at design time within Beans-compliant builder tools. Typically there are two ways to customize a Bean:

Property Editors

A property editor is a tool for customizing a particular property type. Property editors are typically displayed in, or activated from property sheets. A property sheet will determine a property's type, look around for a relevant property editor, and display the property's current value in a relevant way.

Property editors must implement the PropertyEditor interface. PropertyEditor provides methods that specify how a property should be displayed in a property sheet.

Here is the BeanBox's Properties sheet containing OurButton properties:

You begin the process of editing these properties by clicking on the property entry in the sheet.

How each of these is displayed depends on which PropertyEditor methods you implement to return non-null (or equivalent) values.

For example, the int property editor implements the setAsText() method. This indicates to the property sheet that the property can be displayed as a String, hence an editable text box will do.

The Color and Font property editors use a separate panel, and merely use the property sheet to display the current property value. The editor is displayed by clicking on that value. To display the current property value "sample" within the property sheet you need to override isPaintable() to return true, and override paintValue() to paint the current property value on a rectangle in the property sheet. Here's how ColorEditor implements paintValue():

public void paintValue(java.awt.Graphics gfx, java.awt.Rectangle box) {
        Color oldColor = gfx.getColor();
        gfx.setColor(Color.black);
        gfx.drawRect(box.x, box.y, box.width-3, box.height-3);
        gfx.setColor(color);
        gfx.fillRect(box.x+1, box.y+1, box.width-4, box.height-4);
        gfx.setColor(oldColor);
}
To support the custom property editor, you need to override two more methods: Override supportsCustomEditor() to return true, and override getCustomEditor() to return a custom editor instance. ColorEditor.getCustomEditor() returns this.

Additionally, the PropertyEditorSupport class maintains a PropertyChangeListener list, and fires property change event notifications to those listeners when a bound property is changed. For example

How Property Editors are Associated with Properties

Property editors are discovered and associated with a given property by

The BDK Property Editors

The BDK provides property editors for the primitive data types like int bool, and float, and Color and Font class types. The source code for these property editors is in beans/apis/sun/beans/editors. These sources make a good starting point for writing your own property editors. Some things to note about the BDK property editors:

The source code for these property editors is in beans/apis/sun/beans/editors.

Note that if no property editor is found for a property, the BeanBox will not display that property in the Properties sheet.

Customizers

When you use a Bean Customizer, you get complete control over how to configure or edit a Bean. A Customizer is like an application that specifically targets a Bean's customization. Sometimes properties are insufficient for representing a Bean's configurable attributes. Customizers are used where sophisticated instructions would be needed to change a Bean, and where property editors are too primitive to achieve Bean customization.

All customizers must:

If a Bean that has an associated Customizer is dropped into the BeanBox, you will notice a "Customize..." item on the Edit menu.

BDK Customizers

UNDER CONSTRUCTION

The OurButtonCustomizer serves as an example that demonstrates the mechanics of building a customizer. OurButtonCustomizer:

The BridgeTester and JDBC Select demo Beans also have customizers.


Previous | Next | Trail Map | JavaBeans Tutorial | Writing Advanced Beans
Previous | Next | Trail Map | JavaBeans Tutorial | Writing Advanced Beans


Using BeanInfo


The following documentation will help you learn about the BeanInfo class:

A Bean can implicitly expose its properties, events, and methods by conforming to design patterns which are recognized by low-level reflection. Alternatively, a Bean can explicitly expose features in a separate, associated class that implements the BeanInfo interface. You can use the BeanInfo interface (or its convenience class SimpleBeanInfo) to explicitly expose design time information for Beans aware builder tools.

By using an associated BeanInfo class you can

BeanInfo defines methods that return descriptors for each property, method, or event that is to be exposed in a builder tool. Here's the prototypes for these methods:

PropertyDescriptor[] getPropertyDescriptors();
MethodDescriptor[]   getMethodDescriptors();
EventSetDescriptor[] getEventSetDescriptors();
Each of these methods returns an array of descriptors for each item that is to be exposed in a builder tool.

Creating a BeanInfo Class

We'll use the ExplicitButtonBeanInfo to illustrate BeanInfo class creation. Here are the general steps to make a BeanInfo class:

  1. Name your BeanInfo class. You must append the string "BeanInfo" to the target class name. If the target class name is ExplicitButton, then its associated Bean information class must be named ExplicitButtonBeanInfo
  2. Subclass the SimpleBeanInfo class. This is a convenience class the implements BeanInfo methods to return null, or an equivalent noop value.
         public class ExplicitButtonBeanInfo extends SimpleBeanInfo {
         
    Using this class saves you from implementing all the BeanInfo methods; you only have to override those methods you need.
  3. Override the methods you need to specify and return the properties, methods, or events that you want. ExplicitButtonBeanInfo overrides the getPropertyDescriptors() method to return four properties:
         public PropertyDescriptor[] getPropertyDescriptors() {
          try {  
           PropertyDescriptor background =
             new PropertyDescriptor("background", beanClass);
           PropertyDescriptor foreground =
             new PropertyDescriptor("foreground", beanClass);
           PropertyDescriptor font =
             new PropertyDescriptor("font", beanClass);
           PropertyDescriptor label =
             new PropertyDescriptor("label", beanClass);
     
           background.setBound(true);
           foreground.setBound(true);
           font.setBound(true);
           label.setBound(true);
             
           PropertyDescriptor rv[] =
             {background, foreground, font, label};
           return rv;
          } catch (IntrospectionException e) {
             throw new Error(e.toString());
            }
         }        
         
    There are two important things to note here:
    • If you leave a descriptor out, that property, event or method not described will not be exposed. In other words, you can selectively expose properties, events, or methods by leaving out those you don't want exposed.
    • If a feature's getter method returns null, low-level reflection is used for that feature. So you can explicitly specify properties, for example, and let low-level reflection discover the methods. If you don't override the SimpleBeanInfo default method, which returns null, low-level reflection will be used for that feature.
  4. Optionally associate an icon with the target Bean.
          public java.awt.Image getIcon(int iconKind) {
            if (iconKind == BeanInfo.ICON_MONO_16x16 ||
                iconKind == BeanInfo.ICON_COLOR_16x16 ) {
                java.awt.Image img = loadImage("ExplicitButtonIcon16.gif");
                return img;
            }
            if (iconKind == BeanInfo.ICON_MONO_32x32 ||
                iconKind == BeanInfo.ICON_COLOR_32x32 ) {
                java.awt.Image img = loadImage("ExplicitButtonIcon32.gif");
                return img;
            }
            return null;
          }
         
    The BeanBox displays this icon next to the Bean name in the ToolBox. You can expect builder tools to do similar.
  5. Specify the target Bean class, and, if the Bean has a customizer, specify it:
         public BeanDescriptor getBeanDescriptor() {
            return new BeanDescriptor(beanClass, customizerClass);
         }
         ...
         private final static Class beanClass = ExplicitButton.class;
         private final static Class customizerClass = OurButtonCustomizer.class;
         

Keep the BeanInfo class in the same directory as it's target class. The BeanBox first looks for a Bean's BeanInfo class in the target Bean's package path. If no BeanInfo is found, then the Bean information package search path (maintained by the Introspector) is searched. The default Bean information search path is sun.beans.infos. If no BeanInfo class is found, then low-level reflection is used to discover a Bean's features.

Using BeanInfo to Control What Features are Exposed

If you rely on low-level reflection to discover your Bean's features, all those properties, methods, and events that conform to the appropriate design patterns will be exposed in a builder tool. This includes any features in all base classes. If the BeanBox finds an associated BeanInformation class, then that information is used instead, and no more base classes are examined using reflection. In other words, BeanInfo information overrides low-level reflection information, and prevents base class examination.

By using a BeanInfo class, you can expose subsets of a particular Bean feature. For example, by not returning a method descriptor for a particular method, that method will not be exposed in a builder tool.

When you use a BeanInfo class

Feature Descriptors

BeanInfo classes contain descriptors that precisely describe the target Bean's features. The BDK implements the following descriptor classes:

The BeanInfo interface declares methods that return arrays of the above descriptors.

Using BeanInfo to Control What Features are Exposed

For base classes: low-level reflection will yield all features; BeanInfo will yield no base class features unless explicitly told to do so.

For properties, events, and methods, any feature left out will not show up. For example, if you have four methods in your Bean but only list three MethodDescriptor objects in your BeanInfo, the fourth method will not be accessible.


Previous | Next | Trail Map | JavaBeans Tutorial | Writing Advanced Beans
Previous | Next | Trail Map | JavaBeans Tutorial | Writing Advanced Beans


Converting Beans into ActiveX Components

ActiveX Bridge section UNDER CONSTRUCTION


Previous | Next | Trail Map | JavaBeans Tutorial | Writing Advanced Beans