On 1 May 2023, at 17:15, Dan Heidinga <heidi...@redhat.com<mailto:heidi...@redhat.com>> wrote:
This "print a warning" approach makes a lot of sense - as you say, it educates users of dynamic agents that action will be required while not impeding the uptake of JDK 21. It also follows the precedent set by the --illegal-access option in JDK 9+. Users who don't want to see the warning in their logs can specify -XX:+EnableDynamicAgentLoading and are then well prepared for JDK 22+. Seems like a win-win approach. Great. I’ve amended the JEP to propose a warning rather than an error: https://openjdk.org/jeps/8306275 I'm still a little dubious of the distinction between tools and libraries being drawn here. In both cases, a responsible person has chosen to deploy the library or the tool in their environment. There's a human in the loop, albeit at different stages as one decision is made during development and the other during deployment. What we meant in the JEP is that a library operates as part of the application and its functionality is part of the application’s functionality (and so a library can make the application non-portable) while the kind of deep troubleshooting that requires the loading of an agent at runtime requires an operator to trigger its functionality. But another distinction would be one of expectation. People expect a deep troubleshooting tool to peer into and perhaps even rummage arbitrarily in the deep internals of the runtime but they don’t expect that of most libraries. For example, people were surprised when their applications broke on JDK upgrades even though the non-portable libraries they used were non-portable by design. While I understand the benefits to the runtime in not allowing dynamic attach as J9 operated in that model (or with limited capabilities for dynamically attached agents) for many years, I also saw the frequent requests to enable more dynamic capabilities for such agents from both vendors and users. The fact that users were frequently requesting it - even though attaching at launch would have resolved their issue - was surprising given how unhappy they were with that solution even though it resolved the issue. Users may demand arbitrary dynamism and users may demand integrity. But because the two are in inherent conflict, and any choice taken on their behalf will make some users unhappy, users must be able to choose between the conflicting options. Prior to strong encapsulation, the effects of a library on integrity were unknowable, so users did not have that choice. Users believed - rightly or wrongly - that some applications restricted the set of options that could be modified when deploying some Java-based applications if they wanted support. I don't have more specifics here but this concern was raised more than once. Setting the heap size was OK, modifying other -XX options was considered not OK. I've heard such stories, too, but an actual report of a difficulty remains elusive. Until we get reports of actual problems that people have encountered, it’s hard to see how a Java application with sophisticated and relatively unusual needs could be deployed and maintained without control over the command line. Java has always required -XX flags for an application to specify its specialised GC needs; I don’t see how requiring such a flag for even more specialised tooling needs could be onerous (quotidian tool use for debugging, monitoring, control, APM, or most in-production profiling does not require the loading of agents at runtime). — Ron
