Disallowing the dynamic loading of agents by default

[Gregg G Wonderly]

I understand you may have personal experiences with how you use Java.  In my experience and others, Java has constantly had fundamental breakage in various details due to lack of understanding, on the platform development team(s) of what people actually do with Java.

Sent from my iPhone

> On Mar 25, 2023, at 5:29 AM, Bernd <ecki at zusammenkunft.net> wrote:
> 
> 
> Gregg i have to disagree, not only is Java one of the most stable platform out there but also the „Enterprise Desktop“ couldn’t care less about the default of this switch. 
> 
> Gruss
> Bernd 
> --
> http://bernd.eckenfels.net
>  
> Von: serviceability-dev <serviceability-dev-retn at openjdk.org> im Auftrag von Gregg Wonderly <greggwon at cox.net>
> Gesendet: Freitag, März 24, 2023 11:42 PM
> An: Andrew Dinn <adinn at redhat.com>
> Cc: Ron Pressler <ron.pressler at oracle.com>; jigsaw-dev at openjdk.org <jigsaw-dev at openjdk.org>; serviceability-dev at openjdk.org <serviceability-dev at openjdk.org>
> Betreff: Re: Disallowing the dynamic loading of agents by default
>  
> Lot’s of people use Java in places where there is no “release” cycle of Java version in control of the users. These are “corporate users” in most cases and they have Java applications that they are using which will just “stop working” when a new version of Java is installed. 
> 
> Over the years, I’ve watch any favoritism towards java on the desktop or as a general solution programing language wane, because it’s undependable as a platform. You never no when something will break as these “stability” changes occur. People who use software systems are in large part not programers or language/platform experts. The in ability of Oracle and many others to understand how detrimental this behavior has been is just mind blowing. 
> 
> People like myself end up looking like whining babies because we come back every once in a while to see if there is something useful happening in Java development that might finally stabilize the platform on the desktop and other business environments and low and behold write-once-run-anywhere is found to still be unimplemented and basically non appreciated. It’s just a sad, sad thing to see happening. 
> 
> Sun first did this with Java 1.2. The Community beat up on Sun severely and everything quieted down for a while. Then we had the JDK 1.5 release where my much mentioned volatile reachability optimizations broke software all over the place. 
> 
> This is not happening in any other language I am aware of. The people at Sun who were causing all the problems seemed to have gone on to Oracle and there is just a core group of people who just do not understand how horrible Java looks these days because of how much basic functionality got completely broken when a new version of Java showed up on general purpose computing and working software just stopped working… 
> 
> Gregg Wonderly 
> 
> > On Mar 24, 2023, at 12:21 PM, 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. 
> > 
> > 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 
> > 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20230325/b0eac768/attachment-0001.htm>