RFR: JDK-6956385: URLConnection.getLastModified() leaks file handles for jar:file and file: URLs [v3]

[Daniel Fuchs]

On Fri, 19 May 2023 15:46:14 GMT, Jesse Glick <duke at openjdk.org> wrote:

>> [JDK-6956385](https://bugs.openjdk.org/browse/JDK-6956385): `JarURLConnection` properly tracks any `InputStream` it itself opened, and correspondingly closes the `JarFile` if necessary (when caches are disabled). However if its underlying `FileURLConnection` was used to retrieve a header field, that would have caused a `FileInputStream` to be opened which never gets closed until it is garbage collected. This means that an application which calls certain methods on `jar:file:/…something.jar!/…` URLs will leak file handles, even if `URLConnection` caches are supposed to be turned off. This can delay release of system resources, and on Windows can prevent the JAR file from being deleted even after it is no longer in use (for example after `URLClassLoader.close`).
>> 
>> [JDK-8224095](https://bugs.openjdk.org/browse/JDK-8224095) was marked as a duplicate, but I think incorrectly. It refers to `FileURLConnection`, and seems to be complaining about the confusing API design of `URLConnection` generally: that it is an object which you might expect to be `Closeable` but in fact it is its `inputStream` which must be `close`d. In JDK-6956385, even when the caller _does_ specifically call `InputStream.close`, a file handle may be leaked.
>> 
>> I managed to build the JDK on both Linux and (Cygwin) Windows to confirm the fix via
>> 
>> 
>> ./build/…-x86_64-server-release/jdk/bin/java test/jdk/sun/net/www/protocol/jar/FileURLConnectionLeak.java
>> 
>> 
>> I also ran jtreg on Linux (this test and various others in nearby packages); on Windows the `make test` target just hung for some reason.
>> 
>> I marked the test `othervm` out of caution, since it is mutating global state, and if it fails will leak a handle and prevent scratch dir cleanup on Windows.
>> 
>> (This is my first contribution, at least after the move to GitHub, so let me know if something is missing here technically or stylistically. None of the contribution guides appear to be up to date.)
>
> Jesse Glick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Leaving `FileURLConnection.is` non-null, and claiming `connected`, even after `closeInputStream` https://github.com/openjdk/jdk/pull/12871#discussion_r1199085883

Marked as reviewed by dfuchs (Reviewer).

I have run tier1, tier2, tier3, and several repeated runs of jdk_net in our CI and haven't observed any failures related to the proposed changes. As far as I am concerned, this looks good. I am going to approve, but it would good to have a second Reviewer in case I missed anything.

-------------

PR Review: https://git.openjdk.org/jdk/pull/12871#pullrequestreview-1436897162
PR Comment: https://git.openjdk.org/jdk/pull/12871#issuecomment-1557432162