Opening -javaagent classes to named modules

[Johannes Kuhn]

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.Bateman at 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
>>