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

[Alan Bateman]

Daniel's summary is useful but changing URLClassPath doesn't feel right. 
Are you in a hurry to find a solution to this? Just asking as I think 
I'd prefer to see other options explored that fixed it in the protocol 
handler instead.

-Alan

On 25/11/2019 13:31, Rob McKenna wrote:
> 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
>>>