In fact, the JVMTI Specification states[1]:
> As an aid to agents that deploy supporting classes on the search path
of the bootstrap class loader, or the search path of the class loader
that loads the main class, the Java virtual machine arranges for the
module of classes transformed by the ClassFileLoadHook event to read the
unnamed module of both class loaders.
Also, you can always add a read edge to a module at runtime, even if the
target module is unnamed. (Either with Module.addReads or
Instrumentation.redefineModule).
But as Alan stated, your classes need to be on the bootstrap classpath
as classes loaded by the bootstrap classloader will not consult the
system classloader. A java agent will always be loaded from the system
classloader, this is specified in the documentation for the
java.lang.instrument package.
-Johannes
[1]:
https://docs.oracle.com/en/java/javase/16/docs/specs/jvmti.html#bcimodules
On 11-May-21 17:35, Fabian Meumertzheim wrote:
Thanks a lot, that works very well. I had already redefined all modules I
encountered, but was not adding the agent JAR to the bootstrap search path.
Fabian
On Tue, May 11, 2021 at 5:18 PM Alan Bateman <alan.bate...@oracle.com>
wrote:
On 11/05/2021 16:10, Fabian Meumertzheim wrote:
I am currently working on a JVM fuzzer (
https://github.com/CodeIntelligenceTesting/jazzer/) and would like to
apply
it also to classes delivered with the JDK, e.g. the image parsers in
javax.imageio.* in the java.desktop module. The fuzzer uses a Java agent
to
add coverage instrumentation (similar to JaCoCo) to classes at runtime.
As opposed to JaCoCo, for technical reasons the fuzzer needs to inject
bytecode referencing a public static byte[] field defined on a class of
the
agent. Since -javaagent does not support Java modules, this class will be
part of the unnamed module and thus can't be "opened" to other modules,
leading to a "NoClassDefFoundError" when the bytecode is injected into a
class in a different module, e.g. java.desktop.
Is there any way to have a Java agent open up a class for direct access
by
named modules? I have full control over the JVM args within the fuzzer,
but
haven't found a way to achieve this.
I don't think this a modules issue, it's more likely a visibility issue
because the boot class loader does not delegate to the application class
loader. If you are instrumenting classes in java.desktop to call into
some supporting classes that the agent provides then you need those
class on the boot class path.
Instrumentation::appendToBootstrapClassLoaderSearch is the API for that.
You'll also need to use redefineModule to change java.desktop to read
the unnamed module of the boot class loader.
-Alan
