On Fri, 26 Jan 2024 08:27:41 GMT, Alan Bateman <al...@openjdk.org> wrote:
>>> BB currently opens the jdk.internal.misc.Unsafe class to a module on a >>> seperate class loader that is not reachable outside an agent, using >>> Instrumentation. >> >> @raphw, may I ask how? Is there any sample code that is not connected to the >> BB code base with its nested classes, interfaces etc.? I know, that caters >> nicely to the fluent DSL BB provides, but to me it is just a maze of code >> that is hard to comprehend. > >> > BB currently opens the jdk.internal.misc.Unsafe class to a module on a >> > seperate class loader that is not reachable outside an agent, using >> > Instrumentation. >> >> @raphw, may I ask how? Is there any sample code that is not connected to the >> BB code base with its nested classes, interfaces etc.? I know, that caters >> nicely to the fluent DSL BB provides, but to me it is just a maze of code >> that is hard to comprehend. > > Agents should not be using the JDK's internal Unsafe. This needs to said in > the strongest possible terms. > > For the discussion, it would be useful to provide a brief summary on what > AspectJ is trying to do with this weaving. This PR was originally about load > time instrumentation defining auxiliary classes, as you might get at compile > time when compiling a source file containing more than one class.. I can't > tell from your comments here or in Eclipse 546305 if this is relevant to what > you are trying to do or not. It may even be better to start a new discussion > on serviceability-dev. @AlanBateman, the AspectJ weaving agent creates an auxiliary class to implement an "around" advice for a method, i.e. a method execution is intercepted and the user has options to do something before optionally calling the target method and then do something afterwards too. In doing so, she can modify method arguments before calling the target method, then also modify the result. Instead of calling the target method, she may also return a result of the expected type instead. Before, after or instead of calling the target method, she can also throw an exception. The target class is transformed in such a way to call the auxiliary class, which necessitates the the aux-class to be in the same classloader as the target class. But because the aux-class is defined while the target class is still being transformed during class-loading, we cannot have any look-up instance pointinmg to it yet. IMO, this is absolutely on topic, which is why the Bugzilla bug is linked to the JDK issue and was discussed with Mandy in this context. @AlanBateman: As for using means to achieve user benefit that the JDK team deems unfit, nobody would do that, if there was an adequate way to provide such user value. Neither AspectJ nor Byte Buddy have a reputation of being some kind of shady hacker tools. ------------- PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1911676808 PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1911680020
