Opening -javaagent classes to named modules
Johannes Kuhn
info at j-kuhn.de
Tue May 11 18:25:54 UTC 2021
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
>>
More information about the jigsaw-dev
mailing list