I spent a few hours going over the list of methods that were supposedly thread-safe and also searched through the API source. I now have an XML annotation file that describes the methods that are supposedly safe to run by any thread.
When I was done with creating that XML file by hand, I looked at it and realized that — without some graphical tool — it was pretty hard to get a quick overview of what classes and methods were affected. The XML format is easy to create, read, and use in the program, but the packages are nested, so it’s hard to consider classes in isolation.
I decided to write a tool that converts an XML annotation file (which I can automatically create from annotated class files, as mentioned before) to a more human-readable format, something like an abbreviated, abstract Java file.
While doing that I realized that my XML file format was ambiguous. If you recall, my file format used to look like this:
It was “concutest/threadcheck” followed by packages, then the class name, and then <class> and <method> tags. There’s no way that a <class> tag could be mistaken for a package or a class name, since class is a keyword; but method isn’t! So it’s not immediately clear if a <method> tag describes a package or class or indeed a method.
I changed the format and put the <method> tags inside the <class> tag. That means now there is a <class> tag even if there aren’t any class-level annotations if there are annotated methods.
The XML annotations above now look like this:
I had to change all the strategies and the XML annotation files that I had already written, of course.
Now that I have created a list of methods that are safe to be run by any thread, I can start on marking many, many classes and methods as unsafe for execution outside the event thread. That should hopefully make things with DrJava more interesting. So far, I discovered nothing serious, even though I haven’t run the unit tests yet. If I don’t find anything, that’s great, it means DrJava is a solid piece of software. But it would be nice to demonstrate my tools on some buggy programs too…
I slightly extended the strategy that adds the thread checks: It’s now able to handle an arbitrary number of XML annotation files. That way I can keep the annotations for the Java API separate from anything else. The instrumentation is running now, and it’s taking a while. I’ve noticed that already when I was instrumenting the drjava-15.jar file. The frequent checks for superclasses and interfaces seem to get very slow whenever jar files are involved.
There are two things that I need to check:
- Is caching of class and method annotations working? What kinds of hit and miss rates am I getting?
- Should I unpack jar files into a temporary directory, work with them as loose class files there, and then pack them back together at the end? That could potentially speed processing up a lot, if the space is available.
This was a productive night of work, now it’s Labor Day and I should work on sleeping for a bit.
