JDK-8020595 : AWT Thread context classloader is incorrectly modified after application start
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 7u25
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • Submitted: 2013-06-24
  • Updated: 2013-07-18
  • Resolved: 2013-07-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7u40Resolved
Related Reports
Duplicate :  
Description
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.
Comments
Fixed by changes for JDK-8017776. Closing as duplicate.
18-07-2013

I think this is duplicate of 8017776 - please verify and close.
17-07-2013