On 16/04/2018 08:11, Rafael Winterhalter wrote:
:
I also think it is essential to being able to inject a class into a
non-opened package. Otherwise one could use a method handle. When
instrumenting classes one already has full privilege for all packages
as an agent can open modules. If one opens packages to define a class,
this would however open the package to the agent's module which is
typically the unnamed module. As this cannot be undone, such a
requirement might therefore be counter-productive to its intend.
It's important to separate the usages.
The Instrumentation object is for tool agents that are doing load time
or dynamic instrumentation. Agents have full power to do anything and
the accessibility of the classes that they instrument does not matter.
With the proposed API, the agent can define classes in the same runtime
package as the class being loaded or transformed, it does not matter if
that the package is open or not.
Libraries doing code injection is different of course. There is no
Instrumentation object in the picture for this scenario. Instead
libraries must be called with a Lookup that has the appropriate access -
that should be the only way that they can inject into runtime packages
that aren't open.
-Alan
