Agent can inject class into Java 9+ bootstrap class loader

[Godin]

Starting from JDK 9 there is java.lang.invoke.MethodHandles.Lookup.defineClass
that can define class even in bootstrap classloader

MethodHandles
  .privateLookupIn(Object.class, MethodHandles.lookup())
  .defineClass(classBytes);

when java.base module opens java.lang package to module of agent,
what can be done by agent itself using java.lang.instrument.Instrumentation.redefineModule

instrumentation.redefineModule(
  Object.class.getModule(),
  Collections.emptySet(), // extraReads
  Collections.emptyMap(), // extraExports
  Collections.singletonMap(
    "java.lang",
    Collections.singleton(Agent.class.getModule())
  ), // extraOpens
  Collections.emptySet(), // extraUses
  Collections.emptyMap() // extraProvides
);

This way agent can be used with JDKs compiled into bytecode version whose instrumentation is not yet supported, e.g. JDK 13 EA (now each new JDK version is compiled into a new bytecode version). And I believe that majority of people do not compile their code into new bytecode version when testing new JDK EA builds, so this will be already useful for them.

For this use-case such approach is IMO

• definitely safer than automation of replacement of class
• and even than usage of ASM with experimental support of new bytecode version, which is as fragile as our previous tricks with downgrade-upgrade.

Furthermore this approach allows to get rid of conflicts with other agents on JDK 9+.

I wrapped reflective calls of these methods into few helper classes to keep compatibility with JDK 5.

[marchof]

@Godin I would prefer to implement a separate IRuntime for this approach and also move it to org.jacoco.core. Looks cleaner to me. This would require some new API like isApplicable().

What I don't like about re-using ModifiedSystemClassRuntime is that there is no actual modification, it just works as the newly injected class looks like a modified class, i.e. has a $jacocoAccess field.

[Godin]

@marchof implemented ClassInjectionRuntime

[marchof]

@Godin As a first step I directly fixed Eclipse warnings, hope this is ok for you. Will have a closer look now.

[marchof]

Some questions...

[marchof]

What is the best error handling strategy here?

A) Just check whether we're on Java 9 and then fail if this runtime can't be initialized?
B) Ignore any error while initialization and simply fall back to ModifiedSystemRuntime?

[Godin]

Changed implementation from second to first.

[Godin]

@marchof doh, not only reflection, but even this doesn't work in case of --illegal-access=deny 😢

[Godin]

In fact

instrumentation.getClass().getMethod(...).invoke(...)

and

Lookup.lookup().bind(instrumentation, ...).invokeWithArguments(...)

are illegal, whereas

java.lang.Instrumentation.class.getMethod(...).invoke(...)

and

Lookup.lookup().findVirtual(java.lang.Instrumentation.class, ...).invokeWithArguments(...)

are legal, because instrumentation.getClass() is sun.instrument.InstrumentationImpl and

module java.instrument {
    exports java.lang.instrument;

    // allow java launcher to load agents in executable JAR files
    exports sun.instrument to java.base;
}

[marchof]

@Godin I really like this reworked, very concise version, thanks! I came across two minor formal issues, please decide whether you want to address them.