A CU faces with memory leak. This seems to occur because Introspector.getBeanInfo()
does not release some resources.

CONFIGURATION:
JDK: 6u15(and later)/JDK7
OS : WindowsXP(SP3, Japanese)


INVESTIGATION:
The following source portion is extracted from JDK6u23.

The program accesses to AppContext at line#162.
If this access is the first time, AppContext.<clinit> starts to run.

---------------------------------------------------------------------------------------------
<j2se/src/share/classes/java/beans/Introspector.java>
 150     public static BeanInfo getBeanInfo(Class<?> beanClass)
 151         throws IntrospectionException
 152     {
 153         if (!ReflectUtil.isPackageAccessible(beanClass)) {
 154             return (new Introspector(beanClass, null, USE_ALL_BEANINFO)).getBeanInfo();
 155         }
 156         Map<Class<?>, BeanInfo> beanInfoCache;
 157         BeanInfo beanInfo;
 158         synchronized (BEANINFO_CACHE) {
 159             beanInfoCache = (Map<Class<?>, BeanInfo>) AppContext.getAppContext().get(BEANINFO_CACHE);
 160             if (beanInfoCache == null) {
 161                 beanInfoCache = new WeakHashMap<Class<?>, BeanInfo>();
 162                 AppContext.getAppContext().put(BEANINFO_CACHE, beanInfoCache);
 163             }
 164             beanInfo = beanInfoCache.get(beanClass);
 165         }
 166         if (beanInfo == null) {
 167             beanInfo = new Introspector(beanClass, null, USE_ALL_BEANINFO).getBeanInfo();
 168             synchronized (BEANINFO_CACHE) {
 169                 beanInfoCache.put(beanClass, beanInfo);
 170             }
 171         }
 172         return beanInfo;
 173     }
---------------------------------------------------------------------------------------------

In  AppContext.<clinit>, AppContext instance is created and the value of 
Thread.currentThread().getContextClassLoader() is set to the field of 
contextClassLoader at line#227.
The referent to the contextClassLoader never be broken.
That seems to result in memory leak.

---------------------------------------------------------------------------------------------
<j2se/src/share/classes/sun/awt/AppContext.java>
221     AppContext(ThreadGroup threadGroup) {
222         numAppContexts++;
223
224         this.threadGroup = threadGroup;
225         threadGroup2appContext.put(threadGroup, this);
226
227         this.contextClassLoader =
228             (ClassLoader) AccessController.doPrivileged(new PrivilegedAction() {
229                     public Object run() {
230                         return Thread.currentThread().getContextClassLoader();
231                     }
232                 });
233     }
---------------------------------------------------------------------------------------------


SAMPLE PROGRAM:

A small program which simulates the above mentioned behavior.
Please unfoled the TP.zip and invoke "java Test" in jdk6ux.

If the referent is broken correctly, the message
"OK: MyClassLoader is not Reference."
appears and this is expected.

On tje other hands, in jdk6u15 and later,
"NG: MyClassLoader is Reference."
 will appear.
This shows that the referent still remains under the situation
when that should be broken.

In this test case, the impact is very small.
However, in actual applications like appli. servers, 
such small leak piles up for long application's run. 
That result in serious memory exhaustion.

Please see the comment section for a little bit more comment by the CU.