Proposal: #ReflectiveAccessByInstrumentationAgents

[Tim Ellison]

mark.reinhold at oracle.com (Mark Reinhold) wrote on 28/06/2016 22:21:15:
> Issue summary
> -------------
> 
>   #ReflectiveAccessByInstrumentationAgents --- As noted in the related
>   issue #ReflectiveAccessToNonExportedTypes [1], the core reflection API
>   cannot be used to gain access to members of packages that are not
>   exported by their defining modules.  Even if that issue is addressed
>   for the use cases cited, a distinct use case is that of 
instrumentation
>   agents that need to enable injected code to invoke non-public methods
>   and access non-public fields.  A possible solution for this use case 
is
>   specifically to provide instrumentation agents with the ability to use
>   core reflection, or some equivalent, even on elements of non-exported
>   packages. [2]
> 
> Proposal
> --------
> 
> Extend the `java.lang.instrument.Instrumentation` interface, and the
> corresponding JVM TI native API, to support a `redefineModule` method.
> This method is roughly analogous to the existing `redefineClasses`
> method.  It will allow instrumentation agents to update an existing
> module, represented by a `java.lang.reflect.Module` object, to read
> additional modules, export additional packages, use additional services,
> and provide additional services.
> 
> Remove the `addModuleReads` method from the `Instrumentation` interface,
> and remove the `AddModuleReads` and `CanReadModule` functions from JNI,
> since they are no longer needed.
> 
> 
> Notes
> -----
> 
>   - This new API will not allow read, export, uses, and provides
>     relationships to be dropped at run time.  The use cases do not
>     require this, and implementing it would be very difficult.
> 
>   - A sufficiently-skilled instrumentation-agent developer can already 
do
>     some of this with the existing API, by injecting new classes into
>     target modules with initializers that invoke the necessary `Module`
>     methods.  This is, however, awkward at best.
> 
>   - Objects that implement the `Instrumentation` interface are already
>     very powerful, since they can be used to redefine arbitrary classes.
>     Just as is the case today, in order to preserve platform integrity
>     instrumentation agents must be coded very carefully so that they do
>     not leak such objects to user code.
> 
> 
> [1] http://openjdk.java.net/projects/jigsaw/spec/issues/
> #ReflectiveAccessToNonExportedTypes
> [2] http://openjdk.java.net/projects/jigsaw/spec/issues/
> #ReflectiveAccessByInstrumentationAgents

I agree with this proposal.  As already pointed out, instrumentation 
agents
are a powerful, somewhat specialist case that suits the full set of 
manipulation
capabilities.

Regards,
Tim

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU