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

[Volkan Yazici]

On Mon, 13 Oct 2025 05:21:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

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

Perfectly fine. 👍

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

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