Hi Ron, Thank you for the response. I’d read the JEP you’ve linked also.
From what I’ve been able to discern, this change will affect a small majority of our customers as it will change how they deploy observability and diagnostics. I’ve spoken to the some of the product owners and they feel that this represents a one-off pain point that they can adjust to. The principal CS that have to deal directly with helping customers deploy had a completely different view point on the subject. As I sift through the noise the filter I’m applying is that I’m generally more interested in easing customer concerns over engineering ones. I’ve read the relevant JEPs several times and I believe I understand the arguments being forth. I’m sorry but I just don’t agree that on by default dynamic loading of an agent has any connection to better code integrity. As someone who had to sit through 2 days of meetings trying to get a call to System.gc() that was happening every 2 minutes resulting in system failures turned off by setting a flag I can tell you that getting an agent dynamically loaded into a runtime isn’t easy to being with. While this experience may seem extreme, it is more common than you’d imagine. As such it is my opinion that this JEP that seems to have more importance to engineers than end users/customers. More over, I feel that it is inflicting an unnecessary change to deployments that is adding to complexity rather than easing it. Other than that, I don’t feel I have anything more of use to add to the conversation except thank you for answering my questions. Kind regards, Kirk > On May 31, 2023, at 4:59 AM, Ron Pressler <ron.press...@oracle.com> wrote: > > > >> On 28 May 2023, at 17:25, Kirk Pepperdine <k...@kodewerk.com> wrote: >> >> >> Call me dumb.. but… I would have the say that the most puzzling piece of >> this entire JEP/proposal is that I’m failing to make the connect between how >> an agent is loaded and how that strengthens integrity. I keep re-reading >> this JEP looking for clues but I keep bumping my head again… "Giving free >> reign to tools would imply giving free reign to libraries, which is >> tantamount to giving up on integrity by default.”. IMO, this is a false >> equivalency that is not supported by any other point in the document. IOWs, >> there is nothing in this document that is giving me a clue as to how turning >> off dynamic attach improves integrity when I can achieve the same effects >> with a direct attach. > > You can’t find the answer to your question in 451 because we factored out the > motivation for 451 (and several other integrated and future JEPs) into the > informational JEP, https://openjdk.org/jeps/8305968, which you must read to > understand the motivation. > > In short, the goal is integrity *by default*, which means that what we seek > not an end to “superpowers" but the explicit granting of superpowers on the > command line. The problem is not superpowers, but superpowers that *are not > explicitly acknowledged by the application*. Agents loaded at startup have > always been explicitly acknowledged by the application, while those loaded > after startup have not. The goal is to make them explicitly acknowledged, not > “turned off”, and then you get the same for both ways of loading agents: the > application explicitly grants superpowers in both situations. We want the > capabilities offered by agents, and we want the application to be able to > track them. > >> What I do know is that turning off dynamic attach by default will cause >> grief to those that already having to cope with exceptionally complex >> deployment. I would argue that the complexity of these deployments have >> dramatically increased since 2017. Do we really want to add to that >> complexity or should we be refocusing on adding features that help to reduce >> that complexity. > > As the informational JEP explains, not having integrity BY DEFAULT, causes > grief too. Do or don’t, someone gets grief. Given that the vast majority of > Java programs never require or want agents — attached dynamically or > otherwise — given that many current uses of dynamically loaded agents are > better served by agents loaded at startup, and given that we have adding a > command line flag on the one hand vs not having integrity by default that > makes it impossible for applications to know the “map” of their codebase (see > the informational JEP), we believe that, when integrated over the entire > ecosystem, more grief is caused by not restricting dynamically loaded agents > than by restricting it. > > — Ron >
