I’m testing a strategy, ChangeCallTargetInstrumentationStrategy
, that automatically changes call targets as specified in a list of “original call target”-“new call target” pairs now. I’ve modified the CreateDecoratorStrategy
to automatically generate this list.
What I don’t know right now is how this is going to affect super()
calls. I think these are just regular calls, so if something performs a super()
call that takes it to a method in a decorated class (the decoree, right now java.lang.Object
), then it will call the decorator instead, which will then call the decoree. This should all work, except for some complications with the different invoke
flavors of Java bytecode. I think invokespecial
may be used to make calls to methods in super classes, but the decorator might not be a superclass. Unless I insert the decorator into the entire hierarchy, i.e. make all classes that previously had the decoree as immediate superclass have the decorator as superclass.
That might be the easier way, actually. I could put the object ID and whatever fields I need into the decorator then. But it also messes with the object hierarchy in a major way, which may turn out to be harder to hide from reflection.
Update
I don’t really know why I didn’t consider this possibility before. It really seems easier now. I think when I started with the business of adding fields to classes, I didn’t anticipate the need to globally replace call targets. I didn’t think about final methods at that time. Now that I need to do that anyway, inserting ProperObject
into the hierarchy seems easier. Right now, I touch all direct descendants of Object
already anyway because I insert the fields. Placing the additional fields into ProperObject
and changing all direct descendants of Object
to have ProperObject
as superclass is easier.