Accessing module internals from bytecode rewriting agent

[Michael Rasmussen]

On 15 June 2017 at 21:31, Jeremy Manson <jeremymanson at google.com> wrote:
> My initial thought in this general direction was to write a JVMTI agent
> that takes a list of JAR files as arguments.  It then does two things:
>
> - Intercepts all loads of classes using the ClassFileLoadHook, checks to
> see if there is a class with that name in the JAR file, and, if so, uses
> that one instead.  That way, if you try to load java.util.HashMap, it will
> replace the bytes the system is trying to load from rt.jar (or whatever)
> with the bytes from the provided JAR.

If going that route, then there are 3 capabilities added with JVMTI 9
that you should look into, in order to be able to intercept the
loading of the very early classes as well (Object, String, Class etc):
can_generate_early_vmstart
can_generate_all_class_hook_events
can_generate_early_class_hook_events

Also note, that if your modified classes cause other classes to be
loaded during loading/verification, then you might get into trouble.
For instance if they don't exist in java.base, they won't be found.
Also, we had some issues with a similar approach, where the Reference
class was loaded too soon, causing it to not be correctly registered
as a reference class in the VM, which caused crashes during GC
(happening a lot later, after main() had started).

/Michael