Suggestion: allow accessible reflection on protected methods of exported types.

[Andrew Dinn]

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