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