Proposal: #ReflectiveAccessByInstrumentationAgents

[Mark Reinhold]

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