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

[Daniel Fuchs]

On Wed, 8 Oct 2025 10:20:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> 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.

If I'm not mistaken at least FileInputStream has a cleaner to close its file descriptor:
https://github.com/openjdk/jdk/blob/23fcbb0badbef6d22f63ca6c5b26b0693002592c/src/java.base/share/classes/java/io/FileInputStream.java#L140

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

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