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

[Bernd]

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

src/java.base/share/classes/sun/net/www/protocol/jar/JarURLConnection.java line 97:

> 95:                     }
> 96:                 } finally {
> 97:                     if (jarFileURLConnection instanceof FileURLConnection fileURLConnection) {

I Wonder if closing all urlconnection types or the ones with a special interface instead of a specific type (which also introduces a dependency) would be the better way? what about other connections with even more temporary resources (like a temporary file copy?)

test/jdk/sun/net/www/protocol/jar/FileURLConnectionLeak.java line 53:

> 51:         // FileURLConnection.is opened implicitly:
> 52:         var conn = u.openConnection();
> 53:         conn.getContentEncoding();

Should it also call getLastModified() just to satisfy the bugs title?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12871#discussion_r1200714487
PR Review Comment: https://git.openjdk.org/jdk/pull/12871#discussion_r1200716271