Hi Ron,Thanks for the reply, I believe we have established a lot of common ground here. I'll try to clarify a couple of the things you found difficult to follow.
On 27/03/2023 11:32, Ron Pressler wrote:
- 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.
It seems to me to be a fairly simple point but I obviously didn't express it very well. Here's another try.
If this is pushed in jdk21 then anyone currently developing or upgrading an app to target jdk21 will only have been able to test on jdk17-jdk20 where they will not encounter the issue. So, his nly leaves them a small window to detect that there will be a problem using agents in jdk21. When jdk21 arrives this may force them to delay deployment or they may even deploy unaware that the problem exists.
If this is pushed in jdk22 instead of jdk21 then anyone who upgrades from jdk17 to jdk21 will not have a problem. Anyone working on an app for deployment on jdk25 will have the opportunity to test on 3 non_LTS releases which might manifest the potential agent problem before deployment.
I hope that explains the problem better.
Of course, I accept that changes to command line options are nothing new. However, I don't quite see how to get from there to the implication that this specific change cannot therefore raise concerns. I think the truth of that conclusion has to depend on details of the change, specifically what the effect might be on users.- 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.
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
