Annotation processors can be useful as a hacky workaround to get some language feature into the Java language.

jOOQ also has an annotation processor that helps validate SQL syntax for:

Plain SQL usage (SQL injection risk)

SQL dialect support (prevent using an Oracle only feature on MySQL)

You can read about it more in detail here.

Unit testing annotation processors

Unit testing annotation processors is a bit more tricky than using them. Your processor hooks into the Java compiler and manipulates the compiled AST (or does other things). If you want to test your own processor, you need the test to run a Java compiler, but that is difficult to do in a normal project setup, especially if the expected behaviour for a given test is a compilation error.

Let’s assume we have the following two annotations:

@interface A {} @interface B {}

And now, we would like to establish a rule that @A must always be accompanied by @B . For example:

// This must not compile @A class Bad {} // This is fine @A @B class Good {}

We’ll enforce that with an annotation processor:

class AProcessor implements Processor { boolean processed; private ProcessingEnvironment processingEnv; @Override public Set<String> getSupportedOptions() { return Collections.emptySet(); } @Override public Set<String> getSupportedAnnotationTypes() { return Collections.singleton("*"); } @Override public SourceVersion getSupportedSourceVersion() { return SourceVersion.RELEASE_8; } @Override public void init(ProcessingEnvironment processingEnv) { this.processingEnv = processingEnv; } @Override public boolean process(Set<? extends TypeElement> annotations, RoundEnvironment roundEnv) { for (TypeElement e1 : annotations) if (e1.getQualifiedName().contentEquals(A.class.getName())) for (Element e2 : roundEnv.getElementsAnnotatedWith(e1)) if (e2.getAnnotation(B.class) == null) processingEnv.getMessager().printMessage(ERROR, "Annotation A must be accompanied by annotation B"); this.processed = true; return false; } @Override public Iterable<? extends Completion> getCompletions(Element element, AnnotationMirror annotation, ExecutableElement member, String userText) { return Collections.emptyList(); } }

Now, this works. We can easily verify that manually by adding the annotation processor to some Maven compiler configuration and by annotating a few classes with A and B. But then, someone changes the code and we don’t notice the regression. How can we unit test this, rather than doing things manually?

jOOR 0.9.10 support for annotation processors

jOOR is our little open source reflection library that we’re using internally in jOOQ

jOOR has a convenient API to invoke the javax.tools.JavaCompiler API through Reflect.compile() . The most recent release 0.9.10 now takes an optional CompileOptions argument where annotation processors can be registered.

This means, we can now write a very simple unit test as follows (and if you’re using Java 12, you can profit from raw string literals! For a Java 11 compatible version without raw string literals, see our unit tests on github):

@Test public void testCompileWithAnnotationProcessors() { AProcessor p = new AProcessor(); try { Reflect.compile( "org.joor.test.FailAnnotationProcessing", ``` package org.joor.test; @A public class FailAnnotationProcessing { } ```, new CompileOptions().processors(p) ).create().get(); Assert.fail(); } catch (ReflectException expected) { assertTrue(p.processed); } Reflect.compile( "org.joor.test.SucceedAnnotationProcessing", ``` package org.joor.test; @A @B public class SucceedAnnotationProcessing { } ```, new CompileOptions().processors(p) ).create().get(); assertTrue(p.processed); }

So easy! Never have regressions in your annotation processors again!