CheckThread.org (Beta)

Avoiding Annotation Clutter

Adding CheckThread annotations to every method on a class will make Java code look ugly and cluttered.

import org.checkthread.annotations.*

public class SomeClass {
  
    @ThreadSafe
    public void someMethod() {
        // do stuff
    }
	
    @ThreadSafe
    public void someOtherMethod() {
        // do stuff
    }

    @ThreadConfined("someThread")
    public void anotherMethod() {
        // do stuff
    }
}

Placing Annotation on Class Definition

To avoid clutter, CheckThread annotations can be applied at the class definition level. The following code is equivalent to the previous example from a CheckThread annotation standpoint.

import org.checkthread.annotations.*

@ThreadSafe
public class SomeClass {
      
    public void someMethod() {
        // do stuff
    }
	
    public void someOtherMethod() {
        // do stuff
    }

    @ThreadConfined("someThread")
    public void anotherMethod() {
        // do stuff
    }
}

If a method does not have an annotation, CheckThread will traverse up to the method's class definition. If that class does not have an annotation and the class is enclosed by another class, CheckThread will traverse to the enclosing class and so on up until the top level class is reached. The first class to provide an annotation will be selected. If no annotations are found for a method, CheckThread will not perform analysis.

Using XML to Express Thread Policies

Instead of adding annotations to our Java classes, we could alternatively add a threadpolicy.xml file to our root top level package on the class path. Whether to use XML or annotations depends on the application and requirements.

See the thread policy xml reference section for details.