views:

10

answers:

1

Hi,

I want a rule that checks that fields and classes are properly annotated with the java concurrency in practice annotations provided by: http://mvnrepository.com/artifact/net.jcip/jcip-annotations

Fields have to be annotated with @GuardedBy and classes have to be annotated with one of @Immutable, @ThreadSafe or @NotThreadSafe.

I have a rule currently applied, which ensures that Spring Dao classes are annotated with @Repository instead of @Service or @Component.

<module name="Regexp">
    <property name="format" 
        value="(@Component|@Service)(.*[\n])*.*class.*Dao.*\{" />
    <property name="message" 
        value="Daos sollten lieber mit @Repository annotiert werden." />
    <property name="illegalPattern" value="true" />
</module>

The Problem with this approach is, that I can only check for some annotation and tell, that the other annotation should better be used instead. This does not help me with the jcip annotation check, because I can't check for "no specific annotation present".

For starters, it would be cool if someone knew how to transform the Dao check above into a check that just ensures, that @Repository is present on classes which names end with Dao. That pattern could then be used to develop the jcip annotation checks.

Or maybe instead of trying to transform the regexp check, maybe there is some way to implement the jcip rules with the token support of checkstyle? This would maybe make the rule robust.

Anyway, I would like to know how to ensure that a specific annotation has to be present on a specific element via checkstyle. Hopefully someone knows this. :)

A: 

Found the solution:

<module name="Regexp">
    <property name="format" value="(interface [a-zA-Z &lt;&gt;]* \{|(@Immutable|@ThreadSafe|@NotThreadSafe)(.*[\n])*.*class [a-zA-Z &lt;&gt;,]* \{)" />
    <property name="message" value="Klassen sollten als @Immutable, @ThreadSafe oder @NotThreadSafe annotiert werden." />
    <property name="illegalPattern" value="false" />
</module>

Also, checking for @GuardedBy does not make any sense, because it depends on the Synchronization Strategy the class uses. Thus it is not always required to add @GuardedBy to the field declaration. And checking for the cases where it is needed is entirely too complex for a simple checkstyle rule. :)

subes