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.


Reply via email to