ADDITIONAL SYSTEM INFORMATION :
Detected in Win 10, JDK 21.0.2+13, but according to sourcecode error is still in master and happen on all OS. However only on Windows it makes a problem in our usecase as the ZipFile can not be deleted from disk as long as JDK still has the file open.

A DESCRIPTION OF THE PROBLEM :
The constructor of JarFile registers a Cleaner that is only executed by chance if a GC runs. If no GC runs the Cleaner is not executed.
jdk.internal.loader.URLClassPath$JarLoader.getJarFile()
https://github.com/openjdk/jdk/blob/38bd8a36704a962f0ad1052fd2ec150a61663256/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L797
calls checkJar() with an JarFile which is never closed when when System.getSecurityManager()==null
https://github.com/openjdk/jdk/blob/38bd8a36704a962f0ad1052fd2ec150a61663256/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L780

The error was reported java.nio.file.FileSystemException: "The process cannot access the file because it is being used by another process" when the still opened zipfile is tried to be deleted.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
zipFile=new ZipFile(file)
use the same file as URLClasspath
zipFile.close(); // should release the filehandle
try to delete the file -> error

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
jar is closed when no longer used.
Probably just use try-with-resource block in jdk.internal.loader.URLClassPath$JarLoader.getJarFile(java.net.URL) for the new constructed Closable JarFile
ACTUAL -
System filehandle still open after jdk.internal.loader.URLClassPath$JarLoader.checkJar(java.util.jar.JarFile)


CUSTOMER SUBMITTED WORKAROUND :
manually invoke a Garbage Collection with System.gc();

FREQUENCY : always