On 15 June 2017 at 21:31, Jeremy Manson <jeremyman...@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
