New candidate JEP: 451: Prepare to Disallow the Dynamic Loading of Agents

[Andrew Dinn]

On 12/05/2023 07:14, Alan Bateman wrote:
> An application main loading an agent into the current VM sounds dubious. 
> The attach mechanism was never intended to support an application to do 
> brain surgery on itself. It was a mistake (in JDK 6) that this ever 
> worked but it took until JDK 9 before this was disabled by default. 
> There may be cases where an application ships with some APM capabilities 
> that involve an agent - that's the scenario that Launcher-Agent-Class 
> was added for in Java 9. It allows an executable JAR to contain both an 
> application (Main-Class) and an agent (Launcher-Agent-Class), with the 
> agent started before the application runs.

I think the Byteman BMUnit tool provides a very good example of why this 
usage is not always 'dubious'. BMUnit is an extension to JUnit/TestNG 
that allows Byteman rules to be injected into test code and/or JDK code. 
The value of this is beyond question as it has enabled hundreds of 
projects and may thousands of tests order to inject faults and validate 
test execution in ways that would not be possible without using an agent.

The key point is that BMUnit dynamically hoists the Byteman agent into 
the test JVM. It is, of course, feasible to configure individual 
JUnit/TestNG executions with the relevant Byteman agent options to 
achieve the same result. Indeed the Byteman project tests the agent and 
BMUnit by doing so. However, as I know well from scripting all those 
tests, per-test agent configuration is laborious and error prone. The 
real evidence that self-hoisting is valuable to the point of being 
necessary is shown by the rocketing use of BMUnit once self hoisting was 
supported.

Of course, since jdk11 it has been necessary fro BMUNit users to provide 
at least one configuration option on the test command line, setting 
property jdk.attach.allowAttachSelf to enable hoisting an agent into the 
JVM. I'm very happy that such a switch exists and must be enabled. To me 
it seems entirely correct to argue that such a powerful capability with 
such far-reaching consequences for the operation of the platform should 
require command line permisison.

What I am not happy with is the idea that legitimate usage of such 
dynamic agent capabilities, like that of BMUnit, have been described in 
the various discussion threads on this JEP and also the integrity JEP in 
more or less pejorative terms.

Just to pick up on a specific comment above (and intending zero 
criticism of either Alan's intentions or his competence to judge the 
matters addressed in these two JEPs) I find it inappropriate and a tad 
dismissive to see BMUnit being lumped into the category of 'dubious' 
'brain-surgery'. BMUnit is designed be used (and is widely used) to 
carefully construct special-case conditions or deliberately drive code 
down specific execution paths that are critical to achieving important 
test coverage. While I appreciate that 'brain surgery' requires skill 
and close attention to what one is doing, as indeed does using BMUnit, I 
am not left with the impression that this term was deployed in order to 
flatter.

n.b. I say this as someone who has no problem with JEP 451. I am also 
highly favourable towards the concerns that motivate the integrity JEP. 
Of course, I hope, in due course and along with other members of the Red 
Hat Java team, to provide detailed editorial comments on the JEP text 
itself. My point here -- as it will be in those comments -- is that the 
language we use, particularly its tone and the precision of its 
application, really matter.

regards,


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