Potential URLClassLoader bug?

[Jaikiran Pai]

Hello Patrick,

This is a known bug https://bugs.openjdk.org/browse/JDK-8315993 which 
gets triggered when the getResource() gets called on a URL returned 
through the URLClassLoader. We know what's causing this but the fix 
isn't straightforward and is currently under investigation.

-Jaikiran

On 10/10/24 7:43 pm, Patrick Reinhart wrote:
> Hi Everybody,
>
> I recently stumbled over a strange behavior within the URLClassLoader under Windows regarding a left open file handle even though everything is handled within try-with-resources blocks.
>
> Here is simple test that passes under Linux & Mac but fails under Windows:
>
>
> import java.io.*;
> import java.net.*;
> import java.nio.file.*;
> import java.util.jar.*;
>
> public class TestURLClassLoader {
>
>      public static void main(String[] args) throws Exception {
>          var testJar = setupJar();
>          try (URLClassLoader cl = new URLClassLoader(new URL[] { testJar.toUri().toURL() })) {
>              var testResource = cl.getResource("testResource");
>              assert testResource != null;
>              try (InputStream in = testResource.openStream()) {
>                  in.transferTo(System.out);
>              }
>          }
>          Files.delete(testJar);
>          assert !Files.exists(testJar);
>      }
>
>      // setting up a simple .jar file with a single resource as example
>      private static Path setupJar() throws IOException {
>          var testJar = Paths.get("test.jar");
>          try (var out = new FileOutputStream("test.jar");
>               var jar = new JarOutputStream(out)) {
>              jar.putNextEntry(new JarEntry("testResource"));
>              var testData = "some data\n".getBytes();
>              jar.write(testData, 0, testData.length);
>          }
>          assert Files.exists(testJar);
>          return testJar;
>      }
> }