Good, I didn’t oversleep again. I just talked to Corky about the dynamic thread checker again. Here’s what he suggested:
- Annotations at class level, e.g.
@OnlyRunBy(...) class Foo { ... }should not apply to all the methods in the class, but only to those methods that are introduced by the class or by one of its subclasses. That would probably avoid a lot of the warnings that I’m generating right now, and if you really want to annotate a method somewhere where it was not introduced, you can still do that using a method annotation. - Certain AWT/Swing methods are always safe, e.g.
java.awt.Component.repaint. If I’m only using method annotations, then these methods just would not be annotated, but if I’m using class annotations, then I may have to have a method annotation that overrides the class annotation. I think I’ll ignore this for now. - AWT/Swing components are probably safe as long as they or any of their subcomponents aren’t “live” yet. He mentioned that methods such as
setVisibleandpackmake an object “live”, but I have to find a more accurate description. Another question is how do I determine that a component is still safe? Do I add a special element to the annotations, e.g.@OnlyRunBy(eventThread=true, AWTsafe=true), or do I go for more general conditions, like@OnlyRunBy(eventThread=true, condition="!isVisible()"). The latter would, of course, be much more difficult, so at least initially I’m opting for the former. But how do I implement that? Do I add a flag to the class and then set it in one of the methods that make an object “live”?
Update: Actually, Sun doesn’t recommend [1] this practice anymore. I found that out while searching the web for texts on Swing and concurrency [2]. So maybe I can save myself the effort. I’ll have to talk to Corky and find out if he really wants this.
- Even on the view side of AWT/Swing, many objects are probably safe, as long as what they’re doing is volatile, i.e. other threads get to see the effects immediately, and as long as they don’t export an object with mutable state. How do I determine that? Well, I don’t know…
Corky really stressed that we should avoid generating many false positives. That’s what he disliked about the static tools that exist, like FindBugs [3]. After writing more unit tests for the instrumentation strategy I’ll start with annotating DrJava’s codebase and from there work my way into the Java API if I have to.
I think I may want a more flexible format of annotations, though. It’s a little problematic that I cannot use the same annotation class on a class or method twice. I would just like the following format much better:
@OnlyRunBy(eventThread=true)
@OnlyRunBy(threadName="helper")
...
If I can specify each allowed or disallowed thread one by one, then it’s much easier to modify just one of them, e.g. by somehow making it conditional:
// running by event thread is always safe
@OnlyRunBy(eventThread=true)
// running by "helper" is safe as long as not "live"
@OnlyRunBy(threadName="helper" AWTsafe=true) ...
Maybe I’ll have to rethink my annotation format…
