I have never seen a need for a non-agent to define a class in a non-existing package. Injection is typically required if you want to work with package-private types or methods which is really only relevant for the Spring framework, but even there I do not think it's such a big area that it cannot be addressed. Non-agent code generation is typically the use of proxies where the code generation framework is sharing a class loader with the user code and there is normally a way to weave it. Agents on the other hand have to deal with unknown class loader hierarchies and it can be necessary to inject code into a common class loader parent without instrumenting classes in this loader or even knowing any classes of this loader. It's really agents where this is required and therefore Instrumentation is a good target for such an addition.
I have never heard about a 'discussion [that] will eventually lead into putting at least some restrictions on agents loaded into a running VM' and as a heavy user and someone who has helped to write a long row of commercial agents and followed them into their use in production and who has seen how helpful they are in reducing deployment complexity, I can only hope that you will change your mind on this. Dynamically attached agents must already run as the same user as the target process. If you are concerned about agents 'illegally intruding' your Java process, I'd say you have bigger security issues at hand and it is already possible to disable dynamic attachment if you want to avoid it. Dynamic attachment has become pretty much the default approach for a lot of Java tooling in production environments. It has proven to be very convenient if a for example a tracing tool is scanning Java processes to attach to them, rather than requiring the deployment operators to be explicitly set up command line arguments which are easily forgotten if they only need to be added in some environments. This reduction in complexity for operations has literally saved millions of dollars to Java users and Oracle customers. This makes Java a popular choice, especially compared to languages such as Go where this is naturally not possible. It's easy and there is no record of this feature doing any harm. I would not see any good reason to restrict this by default. That said, even if it was restricted in the future, this would mean that some of the Instrumentation API methods will throw exceptions in the future. There would not be much difference if an introduced defineClass method would do the same. Am Fr., 16. Apr. 2021 um 19:31 Uhr schrieb Alan Bateman < alan.bate...@oracle.com>: > On 16/04/2021 17:40, Rafael Winterhalter wrote: > > : > > I will try to make my case on the mailing list. I hoped this could get > resolved within the release of Java 17 as this would make it possible to > write agents without use of Unsafe API to support Java 17 and later. Since > agents often are supplementary to a broad range of Java applications, the > LTS release will likely be an important support boundary for years and > years to come. > > > "are supplementary to a board range of Java applications" is part of the > concern with the proposal. If possible, it would be good if the write-up > could separate the requirements for injection/instrumentation by > frameworks at runtime from the requirements of tool agents. If the > requirements cover testing time and mocking then it would useful to > separate those too. > > Just to add to Rémi's comment: For frameworks/libraries, the > Lookup.defineClass and defineHiddenClass APIs are to define classes in > the same run-time package as the Lookup class. There isn't any API for > libraries/frameworks to define class in a "new run-time package". > There's a chunky project there. Part of it is the Lookup API itself, > part of is that there isn't an exposed way to extend the set of packages > in a named module. Mandy has done some exploration on this topic and may > be able to say a bit more about this. > > On Java agents, then I think the discussion will eventually lead into > putting at least some restrictions on agents loaded into a running VM. > Agents started on the command line with -javaagent are all-powerful but > maybe agents loaded into a target VM get a restricted Instrumentation > object that cannot redefine modules or retransform classes in named > modules. The narrower requirement for agents doing load time > instrumentation to define auxiliary classes in the same package as the > class being loaded fits with the intent of the original API and I don't > think is controversial. > > -Alan >
