RFR: 8367561: Getting some "header" property from a file:// URL causes a file descriptor leak [v2]

[Daniel Fuchs]

On Sat, 4 Oct 2025 16:31:30 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   missed pushing the change
>
> src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 145:
> 
>> 143:     public String getHeaderField(String name) {
>> 144:         initializeHeaders();
>> 145:         return super.getHeaderField(name);
> 
> Several header related method implementations in this class have been updated to avoid the `super.XXXX()` calls. The `super.XXX()` implementation was calling `getInputStream()` and ignoring/not using the returned `InputStream`. That call to `getInputStream()` was a way to initiate a readability check and if the File wasn't readable then it would return a different result compared to when it was readable. The use of `getInputStream()` has been replaced by a call to `isReadable()` which does the same checks without leaving around a `InputStream` instance. Apart from that change, the rest of the code that resided in the `super.XXX()` implementation has been literally copy/pasted in these methods to avoid any kind of behavioural change.

The code duplication is a bit distateful. Have you thought about introducing a package protected method in s.n.www.URLConnection e.g. ensureConnectionEstablished()  that would by default call getInputStream()?
Then you could possibly just override this method in the s.n.www.FileURLConnection subclass, instead of having to override all the methods that call getInputStream() just for the sake or replacing getInputStream() with isReadable()?

I haven't experimented with what I'm suggesting here, and maybe you already considered and rejected it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27633#discussion_r2406673378