RFR: 8132359 - JarURLConnection.getJarFile() resource leak when file is not found

[Daniel Fuchs]

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
>