Hello,
https://bugs.openjdk.org/browse/JDK-8219681 is a problem for all users
of `Instrumentation#appendToBootstrapClassLoaderSearch` on Windows
(examples [1][2]). Workarounds such as reusing the JAR file or
performing clean-up on next start are inefficient and error-prone when
multiple JVM processes might be running and accessing / creating the JAR
file concurrently.
The problem consists of two parts:
1. On Windows you cannot delete a file which is still in use
2. Java's `File#deleteOnExit` (respectively custom shutdown hooks) runs
too 'early', while the JVM still has the file open
While (1) cannot be solved, I am wondering if (2) can actually be solved
/ worked around:
`appendToBootstrapClassLoaderSearch` takes a JarFile, and
JarFile/ZipFile supports `OPEN_DELETE`. Since this deletion is
implemented using native OS file system functionality it sounds like
this would work. Alternatively users could maybe subclass JarFile and
have its `close` method delete the file (assuming the JVM does call
`close` eventually before exit), though the `OPEN_DELETE` approach seems
more reliable?
However, that specific approach does not work because the JDK internal
`appendToBootstrapClassLoaderSearch` implementation actually discards
the JarFile object and just uses its file path. Changing that JDK
behavior might break backward compatibility because projects already
assume that they can close the JarFile immediately afterwards [3].
So what do you think about a new overload
`appendToBootstrapClassLoaderSearch(Path jarPath, boolean
deleteOnExit)`? (respectively using File instead of Path, to enforce
usage of the default file system)
The internal implementation could then open the JAR file using
`OPEN_DELETE`.
(The same might apply to
`Instrumentation#appendToSystemClassLoaderSearch` as well)
Kind regards
[1] https://github.com/mockito/mockito/issues/1379
[2] https://github.com/microsoft/ApplicationInsights-Java/issues/3183
[3]
https://github.com/mockito/mockito/blob/a231205b240e7884a63bf0f63440012867a4da21/mockito-core/src/main/java/org/mockito/internal/creation/bytebuddy/InlineDelegateByteBuddyMockMaker.java#L175-L177
