On Fri, 19 May 2023 15:34:45 GMT, Jesse Glick <d...@openjdk.org> wrote:
>> src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java >> line 97: >> >>> 95: is.close(); >>> 96: is = null; >>> 97: connected = false; >> >> Not sure about switching `connected` to false or setting `is` to null. That >> might allow to call `connect` again and might have unintended side effects? > > It depends on whether you consider the new method to be the opposite of > `connect`, toggling between connected and unconnected states. Removing these > two lines would mean that a subsequent call to `getInputStream()` would > return a closed stream, which may or may not be surprising. An aspect of > JDK-8224095 is that the state transitions for `URLConnection` are generally > confusing. For now it seems irrelevant since > `JarURLConnection.jarFileURLConnection` is never used for its input stream. > > ~In fact I think `closeInputStream` could just be moved into > `JarURLConnection.<init>` for this reason.~ No, it cannot, since > `FileURLConnection.is` is opened only if and when a header is requested. Well yes - exactly my point. At the moment if you call getInputStream() twice in succession you will get the same input stream. The transition from not connected to connected is stable. `connect` can only transition once from `false` to `true`. There's nothing that sets `is` back to `null` or `connect` back to `false` so I believe it should stay that way. Let's keep the (behaviour) changes minimal. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12871#discussion_r1199112611
