java.lang.Object | +--java.beans.Introspector
java.beans.BeanInfo
static int | IGNORE_ALL_BEANINFO |
static int | IGNORE_IMMEDIATE_BEANINFO |
static int | USE_ALL_BEANINFO Introspector is the class that does the bulk of the design-time work in Java Beans. |
static java.lang.String | decapitalize(java.lang.String name) A helper method to convert a name to standard Java naming conventions: anything with two capitals as the first two letters remains the same, otherwise the first letter is decapitalized. |
static void | flushCaches() Flush all of the Introspector's internal caches. |
static void | flushFromCaches(java.lang.Class clz) Flush the Introspector's internal cached information for a given class. |
static java.beans.BeanInfo | getBeanInfo(java.lang.Class beanClass) Get the BeanInfo for class |
static java.beans.BeanInfo | getBeanInfo(java.lang.Class beanClass, java.lang.Class stopClass) Get the BeanInfo for class |
static java.lang.String[] | getBeanInfoSearchPath() Get the search path for BeanInfo classes. |
static void | setBeanInfoSearchPath(java.lang.String[] beanInfoSearchPath) Set the search path for BeanInfo classes. |
public static final int IGNORE_ALL_BEANINFO
public static final int IGNORE_IMMEDIATE_BEANINFO
public static final int USE_ALL_BEANINFO
Don't worry about it too much, though: you can provide JavaBeans with as much customized information as you want, or as little as you want, using the BeanInfo interface (see BeanInfo for details).
Order of Operations
When you call getBeanInfo(class c), the Introspector
first searches for BeanInfo class to see if you
provided any explicit information. It searches for a
class named
If it does not find a BeanInfo class, it acts as though
it had found a BeanInfo class returning null from all
methods (meaning it should discover everything through
Introspection). If it does, then it takes the
information it finds in the BeanInfo class to be
canonical (that is, the information speaks for its
class as well as all superclasses).
When it has introspected the class, calls
getBeanInfo(c.getSuperclass) and adds that information
to the information it has, not adding to any information
it already has that is canonical.
Introspection Design Patterns
When the Introspector goes in to read the class, it
follows a well-defined order in order to not leave any
methods unaccounted for. Its job is to step over all
of the public methods in a class and determine whether
they are part of a property, an event, or a method (in
that order).
Properties:
If there is a pair of methods,
If the addXXX() method throws
Spec Note: the spec seems to say that
the listener type's classname must be equal to the XXX
part of addXXX() and removeXXX(), but that is not the
case in Sun's implementation, so I am assuming it is
not the case in general.
Methods:
Any public methods (including those which were used
for Properties or Events) are used as Methods.
Events:public boolean isXXX()
method, then XXX is a read-only boolean property.
boolean getXXX()
may be supplied in
addition to this method, although isXXX() is the
one that will be used in this case and getXXX()
will be ignored. If there is a
public void setXXX(boolean)
method,
it is part of this group and makes it a read-write
property.public <type> getXXX(int)
method, then XXX is a read-only indexed property of
type <type>. If there is a
public void setXXX(int,<type>)
method, then it is a read-write indexed property of
type <type>. There may also be a
public <type>[] getXXX()
and a
public void setXXX(<type>)
method as well.public void setXXX(int,<type>)
method, then it is a write-only indexed property of
type <type>. There may also be a
public <type>[] getXXX()
and a
public void setXXX(<type>)
method as well.public <type> getXXX()
method,
then XXX is a read-only property of type
<type>. If there is a
public void setXXX(<type>)
method, then it will be used for the property and
the property will be considered read-write.public void setXXX(<type>)
method, then as long as XXX is not already used as
the name of a property, XXX is assumed to be a
write-only property of type <type>.PropertyVetoException
, then the
property in question is assumed to be constrained.
No properties are ever assumed to be bound
(Spec Note: this is not in the
spec, it just makes sense). See PropertyDescriptor
for a description of bound and constrained
properties.public void addXXX(<type>)
and
public void removeXXX(<type>)
, where
<type> is a descendant of
java.util.EventListener
, then the pair of
methods imply that this Bean will fire events to
listeners of type <type>.java.util.TooManyListenersException
, then
the event set is assumed to be unicast. See
EventSetDescriptor for a discussion of unicast event
sets.
java.beans.BeanInfo
public static String decapitalize(java.lang.String name)
name
- the name to decapitalize.public static void flushCaches()
public static void flushFromCaches(java.lang.Class clz)
clz
- the class to be flushed.NullPointerException
- if clz is null.public static BeanInfo getBeanInfo(java.lang.Class beanClass)
beanClass
,
first by looking for explicit information, next by
using standard design patterns to determine
information about the class.
beanClass
- the class to get BeanInfo about.public static BeanInfo getBeanInfo(java.lang.Class beanClass, java.lang.Class stopClass)
beanClass
,
first by looking for explicit information, next by
using standard design patterns to determine
information about the class. It crawls up the
inheritance tree until it hits topClass
.
beanClass
- the Bean class.stopClass
- the class to stop at.public static String[] getBeanInfoSearchPath()
public static void setBeanInfoSearchPath(java.lang.String[] beanInfoSearchPath)
beanInfoSearchPath
- the new BeanInfo search
path.
Don't worry about it too much, though: you can provide JavaBeans with as much customized information as you want, or as little as you want, using the BeanInfo interface (see BeanInfo for details).
Order of Operations
When you call getBeanInfo(class c), the Introspector first searches for BeanInfo class to see if you provided any explicit information. It searches for a class namedBeanInfo in different
packages, first searching the bean class's package
and then moving on to search the beanInfoSearchPath.
- If there is a
- If there is a
- If there is a
- If there is a
- If there is a
- In all of the above cases, if the setXXX() method
throws
Events:
If it does not find a BeanInfo class, it acts as though it had found a BeanInfo class returning null from all methods (meaning it should discover everything through Introspection). If it does, then it takes the information it finds in the BeanInfo class to be canonical (that is, the information speaks for its class as well as all superclasses).
When it has introspected the class, calls getBeanInfo(c.getSuperclass) and adds that information to the information it has, not adding to any information it already has that is canonical.
Introspection Design Patterns
When the Introspector goes in to read the class, it follows a well-defined order in order to not leave any methods unaccounted for. Its job is to step over all of the public methods in a class and determine whether they are part of a property, an event, or a method (in that order). Properties:
public boolean isXXX()
method, then XXX is a read-only boolean property.boolean getXXX()
may be supplied in addition to this method, although isXXX() is the one that will be used in this case and getXXX() will be ignored. If there is apublic void setXXX(boolean)
method, it is part of this group and makes it a read-write property.public <type> getXXX(int)
method, then XXX is a read-only indexed property of type <type>. If there is apublic void setXXX(int,<type>)
method, then it is a read-write indexed property of type <type>. There may also be apublic <type>[] getXXX()
and apublic void setXXX(<type>)
method as well.public void setXXX(int,<type>)
method, then it is a write-only indexed property of type <type>. There may also be apublic <type>[] getXXX()
and apublic void setXXX(<type>)
method as well.public <type> getXXX()
method, then XXX is a read-only property of type <type>. If there is apublic void setXXX(<type>)
method, then it will be used for the property and the property will be considered read-write.public void setXXX(<type>)
method, then as long as XXX is not already used as the name of a property, XXX is assumed to be a write-only property of type <type>.PropertyVetoException
, then the property in question is assumed to be constrained. No properties are ever assumed to be bound (Spec Note: this is not in the spec, it just makes sense). See PropertyDescriptor for a description of bound and constrained properties.If there is a pair of methods,
public void addXXX(<type>)
andpublic void removeXXX(<type>)
, where <type> is a descendant ofjava.util.EventListener
, then the pair of methods imply that this Bean will fire events to listeners of type <type>.If the addXXX() method throws
java.util.TooManyListenersException
, then the event set is assumed to be unicast. See EventSetDescriptor for a discussion of unicast event sets.Spec Note: the spec seems to say that the listener type's classname must be equal to the XXX part of addXXX() and removeXXX(), but that is not the case in Sun's implementation, so I am assuming it is not the case in general.
Methods:
Any public methods (including those which were used for Properties or Events) are used as Methods.