(Moving to the appropriate mailing lists for the discussion of this JEP) We want reports of common uses of dynamically loaded agents for serviceability and difficulties setting a flag. Our judgment will sway if we learn that the use of dynamically loaded agents for serviceability is very common and that setting a command line flag is onerous. Such reports of “I use dynamically loaded agents for X and it’s hard for me to set a flag because Y” should be made here, i.e. jigsaw-...@openjdk.org, serviceability-dev@openjdk.org.
Saying “I don’t like this (because I can think of cases where it may inconvenience me a little)” is not a report of a problem. A JDK feature that is disliked by only 1% of users will still be disliked by tens of thousands of people, and pretty much every JDK feature or lack of a feature is disliked by some Java developers; some features even inconvenience some minority of users. By physical necessity we sometimes inconvenience some users because users have contradictory requirements. What we’re trying to estimate is just *how much* of an inconvenience will be caused by feature X or the lack of X when integrated over the entire ecosystem. — Ron > On 12 May 2023, at 12:37, Jack Shirazi <ja...@fasterj.com> wrote: > > Thanks, this is going in circles. You want reports, I'm fine with that, I > will provide a report. But my one report is not going to be sufficient to > move your judgement. So I'll ask once again where should further such reports > go, and at what point does your judgement sway? > > > On 12/05/2023 16:46, Ron Pressler wrote: >> Let’s start with you describing the particular use-cases of dynamically >> loaded agents that you’re concerned about and why you think a command-line >> flag to enable the functionality is onerous. In other words, describe the >> nature and severity of a *problem*. Remember that the goal of JDK >> maintainers is to serve the ecosystem as a whole, which means accommodating >> the conflicting desires by different classes of users. Because different >> people’s requirements are sometimes in contradiction with one another, we >> need to make a judgment. As JEP 451 says, this judgment is based on the >> assumptions that: 1. The need for dynamically loaded agent is not very >> common, and 2. When needed, adding a flag is not onerous. >> >> Stating you don’t like a policy that’s been discussed for roughly a decade >> and started to be put into effect five years ago is not enough. However, if >> you have questions regarding the informational JEP that attempts to >> summarise past discussions (https://openjdk.org/jeps/8305968) I’ll gladly >> try and answer them. >> >> — Ron >> >>> On 12 May 2023, at 10:05, Jack Shirazi <ja...@fasterj.com> wrote: >>> >>> >>>> Integrity must be opt out, and cannot be opt in, and so opting in is not a >>>> solution that will give us integrity*by default*. >>>> Seehttps://openjdk.org/jeps/8305968#Strong-Encapsulation-by-Default >>> This is an opinion, not a statement of fact. It needs to be justified, not >>> assumed. Integrity is a goal, and there is a balance between what is useful >>> and what can be limited. For full integrity, don't use the JVM at all. I >>> for one prefer to continue using it. >>> >>>> The only information of relevance would be reports showing that >>>> dynamically loading agents are a commonly-needed functionality and that >>>> adding a command-line option to allow it is onerous. >>> I'm fine with that. I'm reporting exactly that here. I encourage others >>> interested in this to also report that. I'll mention it in my next >>> newsletter - where do you want the reports sent? My readers won't want to >>> signup to this email list just to send a comment. At what point does the >>> reporting mean the JEP is dropped? >>> >>> >>> On 12/05/2023 14:44, Ron Pressler wrote: >>>>> On 12 May 2023, at 05:26, Jack Shirazi <ja...@fasterj.com> wrote: >>>>> >>>>> Thank you for your reply. This makes it clear that the JEP has a single >>>>> specific tradeoff. So we have two capabilities at issue here >>>>> >>>>> A) Currently libraries can turn themselves into agents >>>>> >>>>> B) Currently agents can remotely attach >>>>> >>>>> The JEP has decided for the community that each of these are a bad thing >>>>> and should be disabled by default (though enableable by setting an >>>>> option). >>>> No, the JEP says: >>>> >>>> "To assure integrity, we need stronger measures to prevent the misuse by >>>> libraries of dynamically loaded agents. Unfortunately, we have not found a >>>> simple and automatic way to distinguish between a serviceability tool that >>>> dynamically loads an agent and a library that dynamically loads an agent.” >>>> >>>> The only problem is libraries, but because there’s no simple way to >>>> distinguish between the two, and because dynamically loaded agents are not >>>> needed in most serviceability uses, disabling them by default is >>>> reasonable. BTW, this was already decided in 2017 in JEP 261: >>>> https://openjdk.org/jeps/261 >>>> >>>> As the JEP also says, in the future we may be able to distinguish between >>>> tools and libraries via a more complex mechanism that could allow tools to >>>> load agents dynamically without the flag. >>>> >>>> >>>>> My involvement in community discussions over the years has been that no >>>>> one complains about (A), it has not been used maliciously, and there is a >>>>> small niche who use it. (B) is used quite a lot and enhances JVM >>>>> serviceability with a capability that is a clear advantage over other >>>>> runtimes. It seems a shame to eliminate that competitive advantage. >>>> Malicious use is not a concern *at all*. What this JEP addresses is >>>> integrity by default. See https://openjdk.org/jeps/8305968 >>>> >>>>> The JEP clearly points out that anyone concerned by these can disable the >>>>> ability with a simple command-line option, so there is a simple solution >>>>> for this minority. >>>> Integrity must be opt out, and cannot be opt in, and so opting in is not a >>>> solution that will give us integrity *by default*. See >>>> https://openjdk.org/jeps/8305968#Strong-Encapsulation-by-Default >>>> >>>> >>>>> The fundamental error is really that the attaching agent is read-write >>>>> rather than read-only. If we could change that, it would be ideal, but >>>>> sadly I don't think that's easily doable. >>>> Perhaps, but most uses of dynamically loaded agents (and nearly all uses >>>> of dynamically loaded *Java* agents) are for “write.” The most common >>>> use-case for “read-only” is dynamically attached advanced profilers that >>>> use JVM TI. The solution there, as the JEP says, is not to separate agent >>>> capabilities but to improve JFR’s capabilities — which do not require an >>>> agent at all — and JFR can obtain profiles far more efficiently than >>>> anything JVM TI could ever hope to achieve. >>>> >>>>> I and many in the monitoring community believe this JEP is NOT an >>>>> enhancement to the JDK. The proposers believe it is. Is there a mechanism >>>>> other than this email discussion list to gain wider community feedback so >>>>> we can ascertain if there is really a strong community preference either >>>>> way? >>>>> >>>> The only information of relevance would be reports showing that >>>> dynamically loading agents are a commonly-needed functionality and that >>>> adding a command-line option to allow it is onerous. >>>> >>>> — Ron
