On 27/03/2026 13:18, Eirik Bjørsnøs wrote:
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?
Or perhaps the problem is that the native libraries assume that the
JarFile points to a file, an "steals" the path by calling
ZipFile.getName instead of actually calling up into JarFile::getEntry
and JarFile::getInputStream.
If the native layer actually did those upcalls, it seems the agent
here could subclass JarFile and return whatever it wanted from
whatever source. Or just filter which entries / packages are found.
Having the VM invoking arbitrary Java code when loading classes to be
defining by the boot class loader would have huge implications. Note
that native API (JVMTI AddToBootstrapClassLoaderSearch) takes a file
path to a JAR file, it would require a change or a new API to allow
anything else.
-Alan
