Revisit need for Introspector.flushFromCaches call in CachedIntrospectionResults [SPR-11356]

[spring-projects-issues]

Juergen Hoeller opened SPR-11356 and commented

As of JDK 7 and apparently also recent JDK 6 versions, java.beans.Introspector has a proper weak cache for BeanInfo objects. As a consequence, we can probably drop our immediate Introspector.flushFromCaches call in the CachedIntrospectionResults constructor - at least on recent JDKs -, not least of it all to avoid the locking implied by that call.

---

Affects: 4.0 GA

Issue Links:

• Improve the performance of BeanInfo lookups in CachedIntrospectionResults [SPR-9014] #13653 Improve the performance of BeanInfo lookups in CachedIntrospectionResults
• CachedIntrospectionResults caching jar entries and creating big pressure on GC [SPR-11818] #16438 CachedIntrospectionResults caching jar entries and creating big pressure on GC

Referenced from: commits 87179b0, defc1d3

[spring-projects-issues]

Juergen Hoeller commented

The underlying problem has been addressed in the JDK itself as of JDK 6 update 21, which is right in the ballpark that we require as a minimum for Spring 4.0: As a consequence, we can unconditionally drop the flushFromCaches call there.

However, for 3.2.x, the situation is more delicate since the support range goes back to older JDK 6 versions and even JDK 5. For that reason, we can't easily backport this; there is arguably too much risk associated with it at this late stage of the branch.

An option available in 3.2.7 is to set the "spring.beaninfo.ignore" property to "true", either as a system property or in a "spring.properties" file in the root of the classpath - provided that the application does not rely on separate *BeanInfo classes next to its actual bean classes. This mode bypasses the JDK's Introspector cache in a backwards-compatible manner and therefore also skips the flushFromCaches call. This is also avoiding repeated ClassLoader access for non-existing *BeanInfo classes, so it's a worthwhile optimization in its own right. See #13653 for a discussion.

Juergen