FULL PRODUCT VERSION :
java version " 1.7.0_25 "
Java(TM) SE Runtime Environment (build 1.7.0_25-b16)
Java HotSpot(TM) Client VM (build 23.25-b01, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
The application fails to locate resources using the AWT Event's thread's getContextClassLoader() call. getContextClassLoader() is returning sun.misc.Launcher$AppClassLoader instead of the expected com.sun.jnlp.JNLPClassLoader.

The AWT Thread's context class loader is correct on initial check of the the AWT Thread (early on in the application's life). However, this is changed sometime later presumably by Java Web Start code. This results in requests to load resources using this class loader to return null. These null resources first manifest themselves as we are unable to load our custom look and feel and subsequently we are unable to load the main classes of our application.

One some machines, this problem appears on every attempt to start the application. On others, it happens only once always after a reboot.


ERROR MESSAGES/STACK TRACES THAT OCCUR :
No error messages are reported other than nulls returned from getResource() call on the ClassLoader.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
The user executable workaround is to enable the Java Console from the Advanced tab of the Java Applet. For some reason the presence of the Java Console enables the correct handling of the ClassLoader.

In code the hack/workaround is to set the proper ClassLoader . (com.sun.jnlp.JNLPClassLoader obtained from the Load class hosting main()) into the system EventQueue.classLoader field using reflection. This works every time.