JDK-7169024 : Provide BeanInfo implementation that was useful for java.beans.Introspector caching
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: java.beans
  • Affected Version: 7u4
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2012-05-15
  • Updated: 2012-06-09
  • Resolved: 2012-06-09
Related Reports
Duplicate :  
JDK-4763438 - Replace uses of @beaninfo with meta facility in core j2se
Relates :  
JDK-7064279 - Introspector.getBeanInfo() should release some resources in timely manner
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.
09-06-2012
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.
16-05-2012