Proposal: #ReflectiveAccessByInstrumentationAgents

[Remi Forax]

----- Mail original -----
> De: "Mark Reinhold" <mark.reinhold at oracle.com>
> À: jpms-spec-experts at openjdk.java.net
> Envoyé: Mardi 28 Juin 2016 23:21:15
> Objet: Proposal: #ReflectiveAccessByInstrumentationAgents
> 
> 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.
> 

I like this proposal !

Rémi

> 
> 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
>