Hi Alan, I have looked into the available options for providing my agent (or indeed any other agent) with access to Reflection and I think the available options, while usable, are a significant limitation wrt to the status quo.
The simplest, safe way to allow an agent to acquire the privileged reflective access available to java.base classes (i.e. not subject to module checks) is for the agent to delegate to an extension class added to java.base using the command line option -Xpatch. Having played around with the relevant class loaders I think that command line option appears to be the only clean way to inveigle a class into a platform module (without begging the question by assuming that you already have the ability to use stuff in java.base such as Unsafe.defineClass). It certainly does not appear to me as if there is any non-ugly way to introduce a class into this module at run time. The only route I could find is temporarily redefining a public method of a java.base class so that it hands over a privileged instance (such as an Unsafe instance) to agent code, making a call to the redefined code, and then redefining the method so that it reverts back to normal. This could probably be made relatively safe (need to worry about recursive calls and ensure it is idempotent in case something else uses the API) but it's pretty tacky and it's a rather crazy path for all agents to have to follow to obtain privileged access. The reason I am unhappy with just using -Xpatch is that it has two usability problems and also raises the issue of redundancy. Firstly, agents can be loaded dynamically when they are needed. That's often true with Byteman where an agent is used to diagnose errant behaviour if and when it happens. If the agent can only do what it needs on the condition that the user had the foresight to start the JVM with the relevant -Xpath option then this is not going to happen in lots of cases. For repeatable problems that's fine -- just restart the JVM. But for intermittent problems this is exactly when you don't want to be kicked by hindsight for your lack of foresight. The second reason is that it requires using two jars, the extension jar used by -Xpatch and then the agent jar. This may sound a small thing but it's easy to underestimate how hard it is for many users to get this sort of thing right, especially when they have to configure access to the jar as a java command line option in a maven pom. I have managed to hide the loading of the Byteman agent jar when running Byteman-based tests in maven by auto-loading the agent dynamically -- all users need to do is ensure that the agent jar and the jar which implement the JTest/TestNG API extensions supported by Byteman are provided as test dependencies. However, I cannot automate setting java command line options from maven. This is going to confuse and, ultimately, lose a lot of users. The redundancy issue is that following this path will require every agent to do something similar, provide a -Xpatch jar, have it /safely/ export an accessor instance to the agent code (and only the agent code) and then have the agent redirect all operations requiring privlege to that accessor instance. Why do all agents need to do this when providing a setAccessible method on class Instrumentation will immediately give every agent a secure channel for doing the same thing? Given the impending guillotine for completion of JDK I intend to raise a JIRA to mark the #ReflectiveAccessByInstrumentationAgents requirement as still needing a fix and suggesting a modification to Instrumenatation as the way to achieve it. If you have any other alternatives to the ones I have described for how to provide agents with java.base privileges I'd be very pleased to hear them and consider them as alternative implementations. Meanwhile I'll look at providing a webrev which implements what would be needed to provide the necessary capability via Instrumenatation. regards, Andrew Dinn -----------
