Name: skT45625 Date: 05/26/2000


java version "1.2.2"
HotSpot VM (1.0.1, mixed mode, build g)

The JavaBeans Introspector class maintains a cache of the BeanInfos of classes
it has already inspected. This means that it doesn't need to perform the time
consuming process of locating property setter and getter methods more than once.
However, the getBeanInfo(..) method then makes a new copy of this information
everytime it's called. This is a big performance problem for the Tomcat servlet
engine which uses a lot of introspection. (I've already sent a note to the
developers' list regarding this issue)

As best I can tell, the Introspector makes a copy of the data to ensure that any
changes made to it don't affect the cached information. However, I would say
that any application which does that is being very rude. The BeanInfo class is
immutable, but it exposes references to mutable descriptor objects. The only
object which should be permitted to modify those descriptors is the BeanInfo
that created them. Tools which inspect a bean should not need to modify the
information they receive.

I suggest adding a flag to the FeatureDescriptor class. Call it something like
"locked" or "frozen" or "immutable" or whatever. Each of the setter methods in
FeatureDescriptor and its sub-classes should first check the value of the flag.
If its true then the set operation should fail with an IllegalStateException.
Note that the new flag need not be visible to the public since only the
Introspector needs access to it.

As the Introspector builds a complete BeanInfo for the class, it should set the
flag on each and every descriptor object it encounters. This allows the BeanInfo
for the class to set all the necessary attributes but makes the descriptor
immutable once its been initialized. The Introspector may freely hand out
references to these objects without concern that they may be tampered with.

This fix requires no API changes but it does affect some of the visible behavior
of the descriptor objects. However, the only programs which might be affected
are probably using the JavaBeans facility in a way that it wasn't designed for.
I think the benefit outweighs the risk.
(Review ID: 105393)
======================================================================