Integrated: JDK-6956385: URLConnection.getLastModified() leaks file handles for jar:file and file: URLs

[Jesse Glick]

On Sat, 4 Mar 2023 21:49:20 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.)

This pull request has now been integrated.

Changeset: 9f98136c
Author:    Jesse Glick <jglick at cloudbees.com>
Committer: Michael McMahon <michaelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9f98136c3a00ca24d59ffefd58308603b58110c7
Stats:     86 lines in 3 files changed: 84 ins; 0 del; 2 mod

6956385: URLConnection.getLastModified() leaks file handles for jar:file and file: URLs

Define FileURLConnection.closeInputStream for use by JarURLInputStream.close.
JarURLConnection properly tracks any InputStream it itself opened,
and correspondingly closes the JarFile if necessary (when caches are disabled).
But 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).

Reviewed-by: dfuchs, michaelm

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

PR: https://git.openjdk.org/jdk/pull/12871