Disallowing the dynamic loading of agents by default

Andrew Dinn adinn at redhat.com
Fri Mar 24 17:21:15 UTC 2023


Hi Ron,

Thank you for providing a heads up on the proposed JEP. The Red Hat Java 
team have been discussing this proposal. We have reviewed the original 
discussion and also the surrounding debate which established 
requirements for adaptation of Jigsaw to incorporate the needs of agents.

As an aside, I'll note that a thorough review was necessary /even/ in my 
case, despite the fact that I was an active party, because the 
discussion occurred, and corresponding decisions were made, quite some 
time ago. I mention this because it may explain the air of surprise and 
the desire to reiterate some of the original debate on the part of some 
respondents in this thread, who perhaps were not party, or only 
tangentially party, to the discussion.

That also suggests that there may be a lot users who are not aware that 
the -XX:+EnableDynamicAgentLoading switch exists or do not really 
understand why it exists i.e. that there is a broad education issue at 
play here.

We do have some concerns about the JEP, specifically about the timing of 
its delivery. These are probably best addressed via the normal review 
process. In particular that will ensure the discussion happens in a more 
suitable and more widely subscribed forum than the Jigsaw list. However, 
I will briefly mention our concerns in this reply. Before that let me 
start with a few disclaimers:

- We acknowledge that there is little to be gained from re-iterating 
arguments made in the previous discussion (although that does not imply 
the JEP review would not benefit from new arguments, especially from 
those who were not involved in that discussion)

   - We recognize that the purpose of the -XX:+EnableDynamicAgentLoading 
switch is to offer a platform integrity guarantee and that this change 
of the default reflects a desire to prioritise integrity over the 
flexibility that agents provide

   - We recognize that the proposal is only proposing to flip a 
configuration default rather than detract from (or modify) available 
functionality

   - We recognize that changing this default will still allow (*most*) 
users to configure the behaviour they desire

   - We recognize that this advance notice has been given precisely to 
ensure that anyone wishing to deploy on jdk21 an app that relies on use 
of agents has time to plan appropriate configuration for their deployment

   - We recognize that this change of default is not being proposed for 
backport and hence that it will largely only affect the relatively small 
number of users who are currently developing for jdk21+

So, given that as a base for our comments where is the beef?

   - Our main concern is, predictably, timing. Clearly, this is a 
future, potential problem rather than a present problem - no one can be 
deploying on jdk21 yet and most developers who are currently preparing 
an app for deployment on jdk21+ will likely encounter the effect of this 
change before actual deployment and be in a position to remedy it. The 
concern is that advertising a change like this and getting users 
prepared to respond to it has always been difficult to achieve. In 
particular we expect a long tail of support problems from users who are 
trying to upgrade deployments from earlier releases to jdk21.
   So, while it is nice to have such early notice of the proposal we 
plan to review its likely impact on our users and how much time we need 
to prepare ourselves and our users to negotiate this change in 
behaviour. Any evidence we obtain to suggest a delay in targeting is 
appropriate will be brought to the JEP review.

   - A second, related concern is that flipping the default for this 
configuration in an LTS release as the first exposure to it for most 
people is more likely to derail deployment plans for users than if the 
default were flipped in a non-LTS release. If this change were deferred 
to jdk22 then that would give those planning deployment on (or upgrade 
to) jdk25 and also those planning to upgrade from jdk17 to jdk21 more 
time to discover and respond to the change.

   - A third concern, already pointed out by Volker, is that some users 
may run their Java apps via launcher apps or scripts that mask access to 
the Java command line. For such users the change of default may mean 
that they lose the option to deploy dynamic agents for important 
ancillary tasks such as observability. We are not clear how many of our 
users this affects but we will be looking into this and hope to bring 
feedback to the JEP review.
   Obviously, this problem can be remedied relatively easily by the 
supplier of the launcher enabling agent use or providing a suitable 
control switch. Our concern is not with how to solve this problem rather 
how the involvement of two parties, supplier and end user, might imply a 
need for the JEP to be targeted to a later release.

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



More information about the serviceability-dev mailing list