[External] : Re: Disallowing the dynamic loading of agents by default

[Ron Pressler]

Hi Andrew!

> On 24 Mar 2023, at 17:21, Andrew Dinn <adinn at redhat.com> wrote:
> 
> 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.

Understood.

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

I would qualify that: we want to prioritise integrity *by default*. Integrity is only practical when it is the default, as adding more integrity rules after the fact is hard to the point of being impractical. Agents in themselves don’t impact that default, but dynamically loaded agents do.

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

Very well, we can certainly discuss timing as part of the JEP discussion.

The JEP itself is rather ambitious because I noticed that most of the strong encapsulation JEPs lacked a substantial motivation section (largely because they had been written before that became the norm) and so strong encapsulation has not been motivated in JEP form, and this is an opportunity to start rectifying that. This is important because some, even in this discussion, are under the impression that integrity is about security. Although security is certainly one of integrity’s impacts (albeit not in the way hypothesised in this discussion) other major impacts are on performance (including, though certainly not limited to, link-time optimisations that are of interest to Project Leyden) and code evolution (the lack of integrity has been, by far, the biggest cause of JDK upgrade issues experienced by many applications an libraries).

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

While we should certainly discuss timing after publishing the draft JEP, I’m not sure how relevant this particular argument is. Those who upgrade from 17 to 21 don’t care which of the versions they skipped introduced a change, and even the deprecation process does not take into account versions for which Oracle and other vendors choose to offer an LTS service. JDK 17 itself also introduced a far bigger tightening of strong encapsulation than the one discussed here. Furthermore, those who wish to upgrade from one version that has LTS offerings to another avail themselves of the LTS service to upgrade not immediately when the new version is released, so they are under no time pressure.

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

This, too, is an argument that’s hard for me to understand. First, many JDK releases require changes to the command line, for various reasons. JDK 17 required bigger changes than the one announced here, and JDK 21 itself may well require other such changes that impact even more applications than this one — making it an opportunity rather than a liability. Second, such changes are normally announced *later* than this one has. If an application under such constraints always uses the current JDK release, then surely a six-month notice is enough, and if it opts to use an LTS service, then it’s under no pressure.

Anyway, let’s continue this discussion after I publish the draft JEP.

— Ron