On Mon, 29 Jan 2024 14:31:10 GMT, Andrew Dinn <ad...@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
