forax at univ-mlv.fr
Wed Jun 29 09:11:12 UTC 2016
----- 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 , 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. 
> 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 !
> - 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.
More information about the jpms-spec-observers