Reputation: 1218
Think of a dynamic, predicated aspect language. Aspects could be invoked (i.e., methods) instead of or before and after an original method. These aspects are switched on and off which happens at runtime. It could even be, that multiple aspects want to change the same method, which will result in a composition of these aspects into a chain of method calls.
The original method is changed by a loadtime compiler (JPLIS and ASM). I got some bytecode looking something like this:
//## baseMethod ##
aload 0 // this
aload ... // some more arguments
invokedynamic # // call the bootstrap method which returns a callsite to be invoked
The interesting part is that the bootstrap method should work in a specific way:
MethodHandle
s are bound to different instances of different types on which they are invoked.MethodHandle
is just bind to other instances, but not to the instance that is calling the bootstrap method. As such, the invocation of the resulting callsite using this should be omitted (the first branch in the alternative below).It may also happen that the original method is directly called, which is totally okay.
It seems to me that MethodHandle
s are the right thing to achieve this.
My question would be if everything is achievable in a single bootstrap method as such that I can chain the method calls as shown in the sequence diagram using a chain of method handles returned from the bootstrap method that are bound to the callsite.
Upvotes: 3
Views: 594
Reputation: 43117
Any branching logic that will decide which aspects to apply to a method invocation have to run at method handle execution time, not at bootstrap time.
You can combine the various handles and the branching logic via
MethodHandles.guardWithTest​(test, target, fallback)
The this
on the stack will be one of the arguments for the handles.
Upvotes: 3