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.
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.