[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR: 8200559: Java agents doing instrumentation need a means to define auxiliary classes [v2]
From:       Alexander Kriegisch <duke () openjdk ! org>
Date:       2024-01-30 1:02:49
Message-ID: rZ2TyCYxB7JqMY1RDUGGrQbMywllrhX8QftJ7NqeVIk=.6885eb39-425c-423c-9d7d-2f4e2efebb24 () github ! com
[Download RAW message or body]

On Mon, 29 Jan 2024 14:31:10 GMT, Andrew Dinn <adinn@openjdk.org> wrote:

> > Bytecode transformation should not be rocket science, but it progressively is \
> > developing in that direction.
> 
> Hmm? Bytecode transformation of the JDK runtime implementation is a lot more \
> complicated than your comments seem to acknowledge

That is, because I was not talking about JDK runtime transformation but about what \
the AspectJ weaving agent does: transformation of application classes during \
class-loading.

I am aware of the fact, that it is also possible to retransform already loaded \
classes, as a special case also bootstrap ones from the JRE. Of course, this is more \
complicated than the simple case. But my point was, that even the simple case is not \
simple, if I need to define classes in an arbitrary class loader - not because \
technically it is difficult, but simply because the JRE API to do so is more and more \
sealed off with each new Java release. This is also what I mean, when I said, that \
developers are not treated as adults but "protected" by well-meaning, but ill-doing \
helicopter parents.

> here's the important thing, _it always has been_.

No, byte code transformation is not complicated per se. Getting the transformed \
classes where they need to be is complicated, but artificially so.

> You need to remember that instrumenting JDK runtime code involves rebuilding the \
> engine that you are driving while you are in mid-flight.

No, I do not need to remember, because I am aware of that fact. It is just off-topic \
here with regard to what I asked about. But that other use case, which I have \
experimented with in another context (test mocking and stubbing) in the past, is an \
intriguing one, too. I am not underestimating anything there, but for AspectJ it is \
simply out of scope. Should I ever decide to add the capability to weave aspects into \
JRE classes, of course that will up the complexity by a notch or two.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1915860036


[prev in list] [next in list] [prev in thread] [next in thread]