> > For white-box testing of code in user modules, build tools and testing frameworks should automatically emit --add-exports, --add-opens, and --patch-module for the module under test, as appropriate (for example, patching the module under test with the contents of the test module allows the testing of package access methods)… APM tools should require the application to deploy their agents with the -javaagent or -agentlib option. This explicitly grants the agent permission to instrument and modify classes. Mocking libraries that employ an agent to change classes' behavior should do the same.
> I.e. mocking libraries should load their agent at startup and have no need to load it dynamically. Exactly! I'm not advocating against this change, but clearly given the popularity of mocking libraries (and likely other related test libraries) this will surely make this change highly visible once enabled. > > 2. I was wondering however about the relation of this JEP with the following property : > > > > ``` > > -Djdk.attach.allowAttachSelf=true > > ``` > > > > This affects the attachment not agent loading, however I believe this JEP should at least mention this property as well as it seems directly tied to one of the mentioned problems about detecting who loads the agent. > > > The JEP already does. It says: > > > To maintain integrity, JDK 9 and later releases prevent code from connecting to the current JVM by default. > > Perhaps I’ll mention the property by name. Indeed thank you, I missed that. Apologies if I missed that in the previous exchanges. Auditability was mentioned, but if functionality has to be restored agent loading will be enabled via `-XX:+EnableDynamicAgentLoading`, but then the code base could load any agent. It might still be possible to audit via ` -Djdk.instrument.traceUsage` but you're still exposed if some functionality is needed. Is it considered to restrain dynamic agent loading to specific libraries, e.g. via an _allow-list_, like the `--add-opens` options or the only option forward to restrain is declaring them via `--javaagent` / `--agentlib`. -- Brice On Wed, May 17, 2023 at 1:21 PM Ron Pressler <ron.press...@oracle.com> wrote: > > > > On 15 May 2023, at 23:24, Brice Dutheil <brice.duth...@gmail.com> wrote: > > > > Hi, > > > > I do share some concerns of the community, however many have voiced it > with a better english that I could ever do. But I'd like to mention two > things: > > > > 1. There is another usage that I think will be visibly impacted : in > tests it's often necessary to alter part of the system to stress some > parts. In doing so some libraries offer these capabilities, often by > relying on an ad hoc agent ; I hope this falls in the useful application of > this mechanism. I understand the goal is mostly about applications running > in production, yet it's likely the effect will be visible well before code > reaches production. > > The informational JEP linked at the beginning of this one ( > https://openjdk.org/jeps/8305968) refers to this use-case when it comes > to both agents and other encapsulation-breaking mechanisms: > > > For white-box testing of code in user modules, build tools and testing > frameworks should automatically emit --add-exports, --add-opens, and > --patch-module for the module under test, as appropriate (for example, > patching the module under test with the contents of the test module allows > the testing of package access methods)… APM tools should require the > application to deploy their agents with the -javaagent or -agentlib option. > This explicitly grants the agent permission to instrument and modify > classes. Mocking libraries that employ an agent to change classes' behavior > should do the same. > > I.e. mocking libraries should load their agent at startup and have no need > to load it dynamically. > > > > > 2. I was wondering however about the relation of this JEP with the > following property : > > > > ``` > > -Djdk.attach.allowAttachSelf=true > > ``` > > > > This affects the attachment not agent loading, however I believe this > JEP should at least mention this property as well as it seems directly tied > to one of the mentioned problems about detecting who loads the agent. > > > The JEP already does. It says: > > > To maintain integrity, JDK 9 and later releases prevent code from > connecting to the current JVM by default. > > Perhaps I’ll mention the property by name. > > — Ron
