j.l.instrument is for tool agent so better to discuss on
serviceability-dev rather than here.
That said, the setup in that closed JBS issue is very strange. The
purpose of appendToBootstrapClassLoaderSearch is to allow
instrumentation of classes in the modules mapped to the boot loader
where the instrumentation adds references to supporting classes provided
by the agent. These classes cannot be unloaded and it seems a bit
reckless to be trying to delete JAR files that may be in use. It may be
that the usages need to be looked at to find out why the agent in this
examples cited is creating hundreds of JAR files in the temp location.
-Alan
On 17/03/2026 16:33, [email protected]
wrote:
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
