On 10/01/17 16:48, Jochen Theodorou wrote: > On 10.01.2017 15:40, Andrew Dinn wrote: > [...] >> That's possible because an agent can use its Instrumentation instance to >> 'export open' the MethodHandles package to a module of its own making >> and then create the Lookup from within that module. > > but that won't work for me in Groovy as a library. The other modules are > already alive and there are instance from classes of those I need to > work with. Even if I created a new Layer depending on bootstrap and add > there manually all of the modules and add "opens" to them I will still > get into trouble I assume, because I strongly expect those classes not > be identical with the original classes. This works then only if I add my > own module loader, which replaces the one used by jigsaw. Which is again > highly intrusive. Imagine for example me adding something like that to > jboss...
Sorry, I conflated details of the two separate cases where I use reflection vs lookups. The version which uses reflection to access non-public method m of class C needs to 'export open' the package of C to the Byteman module so it can legitimately call m.setAccessible. Class Instrumentation allows you to add such exports at runtime and -- yes, indeed -- it does work and you will not "get into trouble" because the classes remain unchanged (only their module's export list is modified). You need your own ModuleFinder to create the module you specify as target for the addExports call but you don't need to take responsibility for loading java.base to make this work (good thing, since you can't do that anyway). > But... hmm... if you create a Lookup from within that module, why do you > still need to add export open? The Lookup then has full rights even > without "export open" I would have expected. The version which uses Lookups only needs to tweak the exports for one module i.e. java.base. It modifies java.base to 'export open' package java.lang.invoke to the Byteman module. That then allows Byteman to call the private constructor for MethodHandle.Lookup() -- alternatively it can access the master Lookup instance in private static field Lookup.IMPL_LOOKUP. Either way it can then mint new Lookups with whatever privilege it wants. > Since the current mechanism with the security manager is deemed to be > not good enough anymore I actually fail to suggest something, since that > is exactly something I would expect the SecurityManager to handle. Well, John Rose did indeed suggest to use the security manager to police this API in the JIRA issue I cited. However, that doesn't make this switch pointless. A s Remi pointed out in a followup to the thread where John made this proposal a major motive for using a MethodHandle instead of reflection is to have a mechanism is more complete and consistent and that the JVM/JDK understands better -- see the following JLS talk for more details: https://www.youtube.com/watch?v=YpZZjxvyIVU&; regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
