Proposals for some open JPMS issues, #ReflectiveAccessByInstrumentationAgents

[Andrew Dinn]

On 05/07/16 09:34, Alan Bateman wrote:
> 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.

Yes, I glossed over the existence of two separate unnamed modules as I
considered it irrelevant to the problem I was presenting (I still do). I
need a solution which will work when my agent code is in either of these
unnamed modules, in particular when it is in the unnamed module of the
application class loader.

The opportunity for what you describe as 'nosy' user code to get access
is, perhaps, similar to what happens in JDK8 but I am not sure it is on
a par now that the module system is being relied on by jdk devs to
safely hide functionality. I really don't want to open up access to nosy
code as it would be a hostage to fortune so I would prefer a solution
which avoids that.

> 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.

I'd be happy to load part of the agent as a module if I could do so
dynamically (even better would be to generate the required classes in a
dynamically created module). Remi's reply seems to indicate that I can
do this using the Layer API. I will take a look at that to see what it
allows me to do.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander