[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
Hi,
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
"foo.jar!/somedir/".
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.
--
-Alex
More information about the jdk-updates-dev
mailing list