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

[Jesse Glick]

On Fri, 19 May 2023 14:05:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This is a good question. I we made `FileURLConnection` `Closeable` or `AutoCloseable`, and called `close()` in `JarURLConnection` when the underlying connection is `(Auto)Closeable` then I believe it could warrant a CSR. On the other hand IIRC the `file:` protocol handler cannot be overridden - so I'm not sure whether we could actually have a custom underlying `URLConnection` - that would need to be carefully evaluated.
>> 
>> Also, as you note, instance of FileURLConnection may be returned to user code - so the fact that the URLConnection implements `Closeable`/`Autocloseable` could be observed, and would also require a CSR.
>> 
>> That said - we could simply expose a close() method on `FileURLConnection` without implementing `Closeable`/`Autocloseable` - and could examine that (implementing `Closeable`/`Autocloseable`) in a different PR - perhaps as a Enhencement request - rather than a bug fix.
>
>> On the other hand IIRC the `file:` protocol handler cannot be overridden - so I'm not sure whether we could actually have a custom underlying `URLConnection` - that would need to be carefully evaluated.
> 
> Strike that. We could have of course a `jar:http://...` URL so the underlying connection is not necessarily a file connection and therefore can come from a custom protocol handler. So a CSR would definitely be needed if we started calling close() on custom URLConnections.

Yes.

Also I noticed that we cannot define `void close() throws IOException` here either, because of https://github.com/openjdk/jdk/blob/44218b1c9e5daa33557aac9336251cf8398d81eb/src/java.base/share/classes/sun/net/www/URLConnection.java#L256-L262 so for now I will go with another method name.

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

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