Both AspectJ and APT provide the following common functionality:

• Ability to intercept annotations.
• Ability to declare custom compiler errors and warnings based off annotation matching.

I attempted to implement an architecture enforcement requirement using both tools. The requirement was simple: a compile error should occur when an attempt is made to access a class annotated with @RestrictedResource unless the caller is annotated with @SuppressRestrictions.

This was relatively simple with AspectJ, the following Aspect provides the enforcement:

 
public aspect RestrictedResourceEnforcer {
    private pointcut accessToRestrictedResource() :
        call(* (@RestrictedResource *).*(..))
                || call((@RestrictedResource *).new(..));
    private pointcut withinUnrestrictedCode() :
        @withincode(SuppressRestrictions) || @within(SuppressRestrictions);
    declare error : accessToRestrictedResource() && !withinUnrestrictedCode():
        "Attempt to access a restricted resource.";
}

The following test demonstrated the compiler error as well as the lack of compiler error should @SuppressRestrictions be used:

 
public class RestrictedResourceEnforcerTest {
    public void testAccessToRestrictedResource() {
        // Compile error: attempt to access restricted resource.
        RestrictedClass restrictedClass = new RestrictedClass();
        // Compile error: attempt to access restricted resource.
        restrictedClass.method1();
    }
    @SuppressRestrictions
    public void testAccessToSuppressedRestrictionResource() {
        RestrictedClass restrictedClass = new RestrictedClass();
        restrictedClass.method1();
    }
    @RestrictedResource
    private static class RestrictedClass {
        public void method1() {
        }
    }
}

Immediately I realised that it is not possible to implement this kind of architecture enforcement using APT without annotating the calling class (i.e RestrictedResourceEnforcerTest). Without marking the calling class, I’m not going to get a process() callback from APT.

This attempt has shown me that APT is only of real use for processing that is completely contained within the annotated class.

I still wanted try APT in direct comparison with AspectJ so I tried enforcing immutability on any class with an @Immutable annotation. I gave up pretty quickly using APT for this because although it is technically possible, it requires a lot of work with ASM to generate the correct source to enforce immutability (i.e. return unmodifiable collections on getters, throw an exception with setters). AspectJ provides a much more maintainable solution without ever having to go near something like ASM.

So I’m left wondering if APT has any value to your regular Java developer (rather than toolkit developer), I don’t think it has. APT’s use-case looks purely in the space of creating extensions to the regular Java compiler to generate bye products directly related to the class with the annotation.

As a general rule I’d break down APT and AspectJ usage as follows:

• Use AspectJ if you need to add a functional requirement to existing entities. Examples include: monitoring, architecture enforcement, transactional functionality.
• Use APT if you need to generate bye products for framework integration. Examples include: schema generation, source code generation tools (e.g. JAXB, JAXWS)

APT is not designed to be updating code to meet a functional requirement, AspectJ is. Instead APT provides a compiler extension that allows you to generate bye products driven by meta data on a class.