On Fri, 19 May 2023 14:05:11 GMT, Daniel Fuchs <[email protected]> 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
