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

[Jaikiran Pai]

On Tue, 7 Oct 2025 14:41:51 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Daniel's suggestion - don't repeat/copy code from super()
>>  - merge latest from master branch
>>  - missed pushing the change
>>  - 8367561: fix inputstream leak
>>  - 8367561: introduce tests
>
> test/jdk/sun/net/www/protocol/file/FileURLConnStreamLeakTest.java line 73:
> 
>> 71:                 "unexpected URLConnection type");
>> 72:         final var _ = conn.getContentEncoding();
>> 73:         Files.delete(this.testFile); // must not fail
> 
> You should probably make sure that the connection is not garbage collected before deleting the file.
> There are very little chances that it consistently would - but you never know.

I had a look at the FileURLConnection hierarchy and the FileInputStream class. None of those have a finalize() nor any cleaners. Which would mean that even if these objects were garbage collected, the underlying file descriptor (used by FileInputStream) would still be open. Having said that, I haven't checked older releases (to which this might get backported). So I've added a `ReachabilityFence` for the `URLConnection` instance.

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

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