Follow-up for my previous message:
If the agent is create a temporary JAR file to put on the boot class
path then I'm wondering why it can't be given its own directory to do
this, and then cleanup after the test run is complete.
I guess that might work, but it would have to be the build tool which
sets up that directory and passes it to the agent through
`-javaagent`. Maybe that would also allow it to be non-temp
(respectively not worry much about concurrency) when using the
`target` directory for the project, defined by the build tool.
That could indeed be a solution, though I am not sure if that would be
desirable for all agent implementations since it would involve
(slightly) more configuration work for users.
That approach (passing the `target` dir as agent argument
through `-javaagent`) might cause problems for concurrent builds, e.g. a
Gradle build which concurrently runs tests with different JDK versions.
In that case the agent cannot use a static file name for the bootstrap
JAR since the concurrent runs might overwrite each others files. So it
would again have to create unique / temp files in that directory.
Creating temp files in `target` might be somewhat better than creating
them in the OS temp dir, but it is also not so great. Especially if the
user does not run `mvn clean ...` / `gradle clean ...` that often, for
better build performance.
So if an agent was able to delete the file passed to
`appendToBootstrapClassLoaderSearch`, that might really be the easiest
solution for agent implementations.
Actually, maybe part of the problem is that
`appendToBootstrapClassLoaderSearch` takes a JarFile in the first place.
I guess from a theoretical perspective something like a
`Function<String, byte[]>` (but probably as dedicated interface with
`throws IOException`) or a JarInputStream would suffice? Though maybe
supporting that within the JVM implementation would be difficult?
