#ReflectiveAccessByInstrumentationAgents

[Andrew Dinn]

Hi Peter,

On 21/04/16 12:09, Peter Levart wrote:
> The situation is not so complicated, I think. . . .

Thank you very much for your example code.

I understand that it will be possible to localize the changes into a
small part of the agent codebase. My problem was not with this factoring
of the code but rather with the build and deployment process.

I was assuming that I would have to locate any jdk9-specific code in a
separate extension jar and ensure that clients consistently hoist both
the jdk9-specific extension jar and the vanilla agent jar into either
the system classpath or the bootstrap classpath when running on JDK9(+).

The alternative was to use the new multi-release jar model to deploy the
agent jar but, of course, I don't suppose that is ever going to work for
JDK6 deployments.

As you say, I can avoid this dilemma simply by bundling all the code
into the one agent jar and instantiating the relevant management classes
indirectly according to whether modules are present or not. That will
ensure that the JDK9(+)-compiled classes are not loaded when running on
JDK8(-).

Thanks once again for your, as ever, very helpful insights.

regards,


Andrew Dinn
-----------