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

[Alex Kashchenko]

Hi,

On 3/1/20, Alex Kashchenko <akashche at redhat.com> wrote:
> 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.

Please review this updated fix to JDK-8232854 for 11u:

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

Webrev: https://cr.openjdk.java.net/~akasko/jdk11u/8232854/webrev.01/

More broad fix to the underlying problem was discussed for jdk-latest
[1][2][3]. It is proposed to proceed with this narrow point fix for
jdk11 (and then jdk8). Updated patch was taken from this email sent by
Rob McKenna [4]. Comparing with the patch originally proposed in
webrev.00: code change to URLClassPath.java is equivalent,
RemoveJar.java test is more thorough. Testing: checked that included
test fails on Windows without the patch and passes with it (on Linux
it always passes), ran relevant parts of JCK.


[1] https://mail.openjdk.java.net/pipermail/net-dev/2020-April/013756.html
[2] https://mail.openjdk.java.net/pipermail/net-dev/2020-May/013884.html
[3] https://mail.openjdk.java.net/pipermail/net-dev/2020-June/014058.html
[4] https://mail.openjdk.java.net/pipermail/net-dev/2019-November/013341.html


-- 
-Alex