On Fri, 16 Apr 2021 20:30:15 GMT, Rafael Winterhalter <winterhal...@openjdk.org> wrote:
>> To allow agents the definition of auxiliary classes, an API is needed to >> allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or >> `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed >> from `sun.misc.Unsafe`. > > Rafael Winterhalter has refreshed the contents of this pull request, and > previous commits have been removed. Incremental views are not available. The > pull request now contains one commit: > > 8200559: Java agents doing instrumentation need a means to define auxiliary > classes I migrate the day https://bugs.openjdk.org/browse/JDK-8200559 finds a solution (and fallback for older JDKs). I can start a new discussion, but briefly summarized from the last time this was on the mailing list: - Agents sometimes need to add classes, for example when intercepting a reactive API where a modified callback subclass is injected, with an extra field, for instance. - The suggestion was that an argument would be provided to ClassFileTransformer which would allow adding classes to the current package. A prototype was created. - The (my) counter argument was that communication between two packages would be difficult then, as the agent does not control class loading order. If the reactive receiver would need to cast a callback object to read the field that was added, the agent's class might not yet have been instrumented and the class would not exist, yielding an error. The receiver instrumebtation can neither inject the class. - Often there is also a need to inject infrastructure into class loaders/modules that the instrumentation relies on, so I argued that the facility shouldn't be added to ClassFileTransformer to begin with, but to Instrumentation. Otherwise one could also "pseudo-transform" classes to inject infrastructure, but that felt unnecessary. - The discussion staled thereafter. ------------- PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1911679253
