Name: jk109818 Date: 03/12/2002


FULL PRODUCT VERSION :
java version "1.4.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta-b65)
Java HotSpot(TM) Client VM (build 1.4.0-beta-b65, mixed mode)

A DESCRIPTION OF THE PROBLEM :
As a response to bug id 4046284 Introspector will allow a
bean to be its own BeanInfo class. This is an important
feature that greatly enhances Introspector usage. However
it is not documented anywhere --- it is not in the API
description for Introspector, nor is it described in the
Java Beans 1.01 spec.

Java1.4 API:
http://java.sun.com/j2se/1.4/docs/api/java/beans/Introspector.html

The description from the link above reads:
--------------------------------------------------------------
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".
-------------------------------------------------------------

This should really say (my insertions marked by enclosing them in *** <...>
***):

-------------------------------------------------------------
For each class "Foo", explicit information may be available if there exists
a corresponding "FooBeanInfo" class *** <(or the class itself)> *** 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 check if the class itself implements the
java.beans.BeanInfo interface. In this case a new instance of the class is
used as the BeanInfo provider. Finally, if this also fails, >***then we take
the final classname component of *** <the ...BeanInfo class 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"***<, if that failed we
would check if "sun.xyz.OurButton" impalements BeanInfo, if yes we would
call the default constructor of the class to obtain a BeanInfo instance. If
this also failed> *** we'd look in each package in the BeanInfo search path
for an OurButtonBeanInfo class. With the default
-------------------------------------------------------------

Note that I am simply describing above the way Introspector works and has
worked since 1.2 alpha in accordance with the response to bug id 4046284.
The API description is the most important to fix, but the Java Beans Spec
1.01 document should also be updated to reflect the described behaviour.

I discovered this feature which greatly simplifies
development for users of our framework by accident. Please
add this feature to the documentation as soon as possible.

This bug can be reproduced always.

CUSTOMER WORKAROUND :
Read the source code of Introspector?!
(Review ID: 143590)
======================================================================