JDK-2208550 : ClassLoader.getResource and loadClass deadlock when signed jar is verified
  • Type: Backport
  • Backport of: JDK-6984901
  • Component: security-libs
  • Sub-Component: java.security
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2011-04-06
  • Updated: 2019-03-13
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 6 JDK 7
6-poolUnresolved 7Resolved
Comments
Sustaining should take over.
13-03-2019

EVALUATION See May-13-2011 Suggested Fix from IBM and details.
13-05-2011

SUGGESTED FIX IBM has implemented, tested, and verified the following fix on *their* JDK. Basically, adding the synchronized keyword to the following methods in java/net/URLClassLoader.java: public URL findResource(final String name) public Enumeration<URL> findResources(final String name) i.e. the declarations become: public synchronized URL findResource(final String name) public synchronized Enumeration<URL> findResources(final String name) Note, the testcase (See parent CR for more details) is not possible to recreate our with an Oracle JDK, because Oracle have not backported the fix for 6440846 to Java 6. This means that the testcase basically serves as a test for the 6440846 hang on the Oracle Java 6 runtime. The customer's hang only occurs with Java 6 when the fix for 6440846 is present. On JDK 7, the testcase did not hang with builds that include the fix for 6440846 (i.e. b55 onwards). IBM further suspects that the changes under CR 4670071 are preventing the Java 6 hang from occurring.
13-05-2011