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

[Jaikiran Pai]

On Wed, 8 Oct 2025 16:03:02 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Daniel's suggestion - add reachability fence
>
> test/jdk/sun/net/www/protocol/file/FileURLConnStreamLeakTest.java line 1:
> 
>> 1: /*
> 
> Converting this entire class to a single `@ParameterizedTest` method (i.e., no instance field, no `@{Before,After}Each`) can avoid significant duplication.
> 
> 
> @ParameterizedTest("connTesters")
> void test(Consumer<URLConnection> connTester) {
>     Path file = Files.createTempFile(Path.of("."), "8367561-", ".txt");
>     try {
>     Files.writeString(file, String.valueOf(System.currentTimeMillis()));
>     URLConnection conn = file.toUri().toURL().openConnection();
>     assertNotNull(conn, "URLConnection for " + file + " is null");
>     assertEquals(FILE_URLCONNECTION_CLASSNAME, conn.getClass().getName(),
>                 "unexpected URLConnection type");
>     connTester.accept(conn);
>     Reference.reachabilityFence(conn);
>     } finally {
>         Files.deleteIfExists(file);
>     }
> }

In my initial experiments I had considered this idea, but I decided to use the present form because it allows me to add additional asserts for some of the API calls more closer in the test method itself, than in the centralized code where the parameters are built for the ParameterizedTest. 

I prefer the present form even if it means repetition of some test code. Would that be OK?

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

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