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
