This week, I’ve successfully tackled the problem with the parameter lists in the reflection-based Thread Checker. Ironically, the parameter names are available when I do my own thing, but when I’m using Java’s convenient, built-in reflection API, the names are pieces of information I cannot get.
So my first step was to enhance the @PredicateLink‘s method attribute. It is now possible to specify the order of the parameters by listing the parameter names in parentheses, e.g. method="myMethod(param1,param2,param3)". The first parameter of type Object, used to pass the value of this if possible, is ignored in this list.
After that was done, I could have rewritten all the method attributes for the annotations. But I realized that I do have the required information when I’m processing the class files, and I need to do that briefly even for the reflection-based Thread Checker. So after the manual process worked, I added an automatic updating function that changed a method attribute without parameters (old format) to a method attribute with parameters (new format). Now all the old annotations work with both Thread Checkers. One problem solved, quite elegantly I think; I just still think it’s ironic that I can’t get the parameter names using reflection…
After that, I added a few more common annotation, e.g. the @Not... flavors for all the @Only... annotations I have, and I added @Any and @None annotations for all of those common annotations, which are @Combine-style annotations that combine using or and and, respectively.
I also separated out the classes that belong just to the annotations, and not to the framework involved in rewriting the bytecode, and put those classes in a separate tclib.jar file. When compiling, only those files are necessary. The full tcrt.lib is only necessary to do the bytecode rewriting and run the Thread Checker. I think separating the two sets of classes was a good idea, because now it is possible to ship a much lighter 34 kB tclib.jar (47 class files) with applications that use it, like DrJava, and only distribute the 734 kB tcrt.jar (617 class files) when the debugging capability is needed.
Mea culpa, though: I still haven’t written more documentation, I still haven’t extended Concutest-JUnit, I still haven’t collected more performance data, and I feel I’m a little behind on my grading (even though the other TAs haven’t done more either). Tomorrow (read: today) I’ll probably hold my last regularly scheduled office hours. Things are moving ahead, albeit slowly.
