Proposals for some open JPMS issues, #ReflectiveAccessByInstrumentationAgents

[Alan Bateman]

On 04/07/2016 13:26, Andrew Dinn wrote:

> :
> As I understand the current situation (after conversations with Alan
> Bateman) all agent classes loaded from an agent jar -- whether the agent
> is deployed on the command line or dynamically, using the VM_Attach API
> -- will belong to the unnamed module _M. My problem turns on the
> question what is the relation between M' and _M?
Just to expand on this. Java agents that are deployed via the -javaagent 
command line option, or loaded into a running VM by means of the Attach 
API, have their types loaded by the application class loader. Some 
agents will also add to the boot class loader search path. From previous 
mails on jigsaw-dev then I think you have this in Byteman so that some 
agent classes are in the unnamed module of the application class loader, 
others are in the unnamed module of the boot loader. With the proposed 
API then you can update any named module to export its packages to 
either (or both) unnamed modules. There will be user code loaded by the 
unnamed module of the application class loader and so exporting to this 
module means that nosy user code on the class path may get access, 
exactly as it does today with JDK 8 and older.

The real issue here is of course that the agent and user code are loaded 
by the same class loader and in the same module. This is for visibility 
reasons of course. We have prototyped support for deploying java agents 
as modules but I think TBD as to whether to go forward with a proposal 
in this or not. That doesn't stop you using the API to do dynamic 
configuration and load part of the agent in a named module. Another 
alternative is to load the security sensitive code into its own class 
loader and use redefineModule to export the packages to the unnamed 
module of that class loader.

-Alan