United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-7169024 : Provide BeanInfo implementation that was useful for java.beans.Introspector caching

Details
Type:
Enhancement
Submit Date:
2012-05-15
Status:
Closed
Updated Date:
2012-06-09
Project Name:
JDK
Resolved Date:
2012-06-09
Component:
client-libs
OS:
generic
Sub-Component:
java.beans
CPU:
generic
Priority:
P4
Resolution:
Duplicate
Affected Versions:
7u4
Fixed Versions:

Related Reports
Duplicate:
Relates:

Sub Tasks

Description
J2SE Version (please include all output from java -version flag):
7u4 and 6u32


Does this problem occur on J2SE 6ux or 7ux?  Yes / No (pick one)
works fine through early Java 5 through recent times with Java 6

Bug Description:
It used to be that one could rely upon java.beans.Introspector caching a given BeanInfo unless it was flushed -- at least as long as the bean class remained loaded.

Have a fair bit of code relying upon this behavior to do JavaBeans persistence.  Various classes in their static initializers retrieve their own BeanInfo and then adjust the transience of properties, set their persistence delegate, etc, therein.  This worked just fine for years -- fairly early Java 5 through rather recent times with Java 6.

Now find that Java 6 Update 32 and Java 7 Update 4 both no longer obey this implicit contract. It seems relate to bug#7064279 fix

    7064279: Introspector.getBeanInfo() should release some resources in timely manner


Workaround: Essentially create an explicit XyzBeanInfo class for each Xyz bean class and do the BeanInfo changes in the constructor.  It would be nice if the JDK provided a BeanInfo implementation that was usable towards this end (SimpleBeanInfo is clearly not as it doesn't return the default property descriptors, etc, and allow you to modify from there)

Overall this is a bit painful for an update release.  Need change ~70 files to address this.

                                    

Comments
EVALUATION

I don't think that a base class for BeanInfo should be provided.  Using a BeanInfo is error prone.  Whenever you alter your class, you need to rebuild your BeanInfo, which risks losing your settings.  I prefer to create annotations, which will affect the Introspector during a BeanInfo generating.  It is clearer and more maintainable.
                                     
2012-06-09
WORK AROUND

ended up doing something like to workaround:

    public class  OverrideableBeanInfo
      implements BeanInfo
    {
      protected final BeanInfo  wrappedBeanInfo;

      public  OverrideableBeanInfo( final Class<?> cls )
        throws IntrospectionException
      {
        wrappedBeanInfo = Introspector.getBeanInfo( cls, Introspector.IGNORE_IMMEDIATE_BEANINFO );
      }

      public BeanDescriptor  getBeanDescriptor()
      {
        return wrappedBeanInfo.getBeanDescriptor();
      }

      ...
    }

and then creating XyzBeanInfo classes that subclass this and tweak the 
wrappedBeanInfo in their constructors.

This seems to do the trick but frankly this approach wasn't terribly 
obvious from the API and this appears to be the only way to intercept 
the BeanInfo that Introspector would generate from a class via reflection, 
adjust it, and then return this as the BeanInfo for a given bean class.
                                     
2012-05-16



Hardware and Software, Engineered to Work Together