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

[Alan Bateman]

On 12/05/2023 11:36, Andrew Dinn wrote:
>
> 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.

I read this as more of convenience than a necessity and I think ties to 
Bruno's point that dependency management leads to dependences on agents 
that end up on the class path with other libraries. Ideally the test 
runners / plugins could specify -javaagent rather than putting the agent 
on the class path.


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

jdk.attach.allowAttachSelf was unpopular but one of the early steps in 
JDK 9 when there was the initial attempts to make progress on the issue.


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

Apologies, it's more of in-joke where the phrase "brain surgery on 
oneself" has long meant loading an agent into the current VM to 
instrument code in the current VM.

In any case, the intention in JDK 6 when we added the attach mechanism 
and dynamically loaded agents is that they be used by tools to load 
profiler/other agents into target VMs / running applications. Later 
usages where it was used to load agents into the current VM came as 
surprise and eventual friction with the efforts over many release to 
more robustly maintain integrity invariants.

-Alan.