Thanks Daniel,
cc'ing core-libs-dev in case there are any objections.
-Rob
On 25/11/19 10:47, Daniel Fuchs wrote:
> Hi Rob,
>
> That looks good to me. I wonder if that should go to corelibs for
> review as well.
>
> The underlying issue here is that JarURLConnection open both its
> jar file and its jar file entry in its connect() method.
> However, it delegates the opening of the jar file to the cache,
> when uses cache is true.
> In this latter case, if opening the entry throws an exception,
> it can't close the jar file because the file might have come from
> the cache and it might still be used by someone else.
> But because getJarFile() calls connect() then there's no way
> to retrieve the jar file through that (failed) connection.
>
> I agree that fixing the issue in URLClassPath is probably the
> less risky.
>
> I see that your test caters for all possible setting of uses cache
> and combination of success/failure when opening the jar entry,
> so this give me confidence that the fix is working as intended.
>
> best regards,
>
> -- daniel
>
>
> On 24/11/2019 15:33, Rob McKenna wrote:
> > Hi folks,
> >
> > If a FileNotFoundException is thrown when attempting to load a class
> > from a jar file, a reference to the open JarFile remains even after the
> > loader is closed. The test in the webrev demonstrates the problem by
> > attempting to delete the JarFile after attempting a class load.
> >
> > The deletion will fail as the JarFile is still in use (i.e. open)
> > despite the fact that the loader has been closed.
> >
> > Note: the behaviour depends on the URLConnections useCaches setting so
> > the test cycles through the combinations. (this helpfully found a problem
> > with an earlier fix attempt)
> >
> > bug: https://bugs.openjdk.java.net/browse/JDK-8132359
> > webrev: http://cr.openjdk.java.net/~robm/8132359/webrev.01/
> >
> > Thanks,
> >
> > -Rob
> >
>
