On Wed, 8 Oct 2025 10:20:59 GMT, Jaikiran Pai <[email protected]> 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
