> > 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. This has actually come up as an issue in some of my experiments in the ZIP/JAR area. If we wanted to support non-file-path ZIP files in the future (in memory, network etc), this API would pose an issue. Cheers, Eirik.
