[11u] RFR: 8232854: URLClassLoader.close() doesn't close cached JAR file on Windows when load() fails

Alex Kashchenko akashche at redhat.com
Sun Mar 1 12:03:00 UTC 2020


Please review the fix to JDK-8232854 for 11u:

Jira issue: https://bugs.openjdk.java.net/browse/JDK-8232854

Webrev: http://cr.openjdk.java.net/~akasko/jdk11u/8232854/webrev.00/

Patch is implemented based on a test code included with the Jira issue. 
It fixes the case, when URLClassLoader is created with URL, that stars 
with "jar:file:" and ends with non-root path inside JAR like 

Codepath in this case includes URLClassPath.Loader class, that requires 
special handling when resources are loaded from a JAR file. Issue with 
closing JAR file (on classloader close) on this codepath was previously 
fixed in JDK-6896088:

Jira issue: https://bugs.openjdk.java.net/browse/JDK-6896088

Changeset: http://hg.openjdk.java.net/jdk/jdk/rev/3af394bb6f59

This fix is complementary to 6896088, it is filling the "jarfile" field 
in URLClassPath.Loader class (to be able to close the JAR file later) in 
case, when requested resource failed to be loaded from this JAR. Note, 
that getJarFile() on URLConnection to original resource cannot be used 
in this case, because this method checks that requested resource is 
valid. URLConnection to the root URL in this JAR is used instead.

There probably exist more elegant solutions to this problem. This patch 
is fix-only and should not affect any existing logic in URLClassPath.

Test included with this fix is similar to 
java/net/URLClassLoader/B6896088.java test. It uses specific JAR 
structure (with a classfile inside "somedir" directory that is not a 
part of class package) and checks JAR file closing after both successful 
and failed load attempts. Test fails on Windows without this patch, on 
Linux it always passes.


More information about the core-libs-dev mailing list