Change Call Target & Create Decorator Strategies

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.

Share

About Mathias

Software development engineer. Principal developer of DrJava. Recent Ph.D. graduate from the Department of Computer Science at Rice University.
This entry was posted in Concurrent Unit Testing. Bookmark the permalink.

Leave a Reply