AspectJ for generating custom compiler errors

One of my favourite uses of AspectJ is to generate compile-time error messages.  This allows you to provide guidance in the IDE for developers writing new code within a framework or library. 

Here’s a quick example. BaseDTO is a base class that developers will extend. It’s used with a framework that requires a no-arg constructor (Jackson in this case, but it’s a common requirement), but when constructed explicitly, the UriInfo parameter is mandatory.

	// No-arg constructor for unmarshalling, but otherwise don't call this one
	public BaseDTO() {}
	public BaseDTO(UriInfo uriInfo) {
		this._links = new Links(uriInfo);

We can’t express that requirement in normal Java. As a result, developers can waste a lot of time debugging a new subclass. AspectJ to the rescue!

public aspect DTOChecker {
	pointcut dtoConstructor(): call( 
	&& !call(, ..));
	declare error : dtoConstructor() :  "DTOChecker: Constructors for subclasses of BaseDTO must include a UriInfo parameter.";


Then, if we try to call a constructor for any subclass of BaseDTO without including a parameter of type UriInfo, we get a compile error. In Eclipse, that looks like this:

AspectJ: using advised class fields

A short post to clarify something that was a little mysterious from the documentation.

AspectJ around advice typically looks something like:

	pointcut myPointCut( ) : execution(void my.package.myClass.myMethod());
	void around(): myPointCut() {
		// do some stuff
		proceed(); // call the advised method
		// do some other stuff

What if I want to call other methods or use fields from myClass in the advice? There are a few moving parts here:

	pointcut myPointCut( ) : execution(void my.package.myClass.myMethod());
	void around(my.package.myClass myClass): target(myClass) && myPointCut() {
		myClass.method1(); // do some stuff
		proceed(myClass); // call the advised method
		myClass.publicField = null; // do some other stuff

To break it down:

  1. Add a parameter to around() with the type of the advised class.
  2. Use the AspectJ target() method to populate that parameter.
  3. Use the parameter value within the advice however you like. But note that you’re limited to public accessible methods and members – despite what you might think, the advice isnot within the lexical scope of the advised class.
  4. Add the parameter value as the first parameter to proceed().

This example is for an advised method with no parameters. If the method has parameters:

	pointcut myPointCut( ) : execution(void my.package.myClass.myMethod(my.package.ParamClass param));
	void around(my.package.myClass myClass, my.package.ParamClass param): target(myClass) 
			&& args(param) && myPointCut() {
		myClass.method1(); // do some stuff
		proceed(myClass, param); // call the advised method
		myClass.publicField = null; // do some other stuff

Multi-project AspectJ builds with Gradle and Eclipse

Using Gradle for build/CI and Eclipse for development is a nice ecosystem with reasonable integration, but things get a bit trickier when we add multi-project builds and AspectJ into the mix. This post steps through some of the manual steps required to get it all working together.


Note: I am using the built-in gradle eclipse plugin, but not the eclipse gradle plugin

The multi-project build

For reasons beyond the scope of this post, I’m using three projects, in order of dependency:

model – a rich domain model
persistence – a project which uses AspectJ to layer a set of generic persistence-aware superclasses on top of model
modelp – a project which takes the emitted classes from persistence and adds all the necessary persistence plumbing, such as hibernate mappings, optimized DAOs, etc.

Gradle configuration

Details irrelevant to the multi-project configuration are omitted.

persistence project:

dependencies {
	ajInpath project(path: ':model', transitive: false)

The persistence project will then emit all of the classes from the model project woven with the aspects from persistence. Note that the upstream dependencies of model are not woven, nor are they automatically available to the persistence project. We need to use the normal gradle dependency mechanisms if we want to do that.

modelp project


dependencies {
	ajInpath project(path: ':persistence', transitive: false)

Eclipse configuration

So far so good. Gradle is pretty clever about wiring up multi-project builds. Eclipse is a little less clever, or maybe just different. So after

gradle eclipse

we still have some manual steps to do to recreate this setup in Eclipse.

AspectJ setup

Edited 7th June 2016, thanks to Daniel’s very helpful comment

Here we come to the first difference between Eclipse and Gradle. If we add the upstream project to the inpath, AspectJ will try to weave all of that project’s referenced libraries as well. In effect, Eclipse is missing the “transitive: false” argument we used in Gradle. This is (mostly) harmless (probably), but it’s slow and can throw spurious errors. So instead of adding the whole upstream project to the inpath, we add the project’s emitted class folder.

Together with adding the AspectJ nature to the project, the gradle code to configure eclipse looks like this for the modelp project:

eclipse {

	project {
		natures = ['org.eclipse.ajdt.ui.ajnature','org.eclipse.jdt.core.javanature']
		buildCommand 'org.eclipse.ajdt.core.ajbuilder'
	// Add the inpath entry to the classpath
	classpath {
		file {
			withXml {
				def node = it.asNode();
				node.appendNode("classpathentry",  [kind:"lib", path:"/model/bin"])
					.appendNode("attributes", [:])
					.appendNode("attribute", [name:"org.eclipse.ajdt.inpath", value:"org.eclipse.ajdt.inpath"]);


Dependent project setup

We still need the upstream project and its libraries to be available to the Eclipse compiler. The gradle eclipse plugin will take care of this if we have a normal compile project dependency in our gradle build (e.g. compile project(":model")), but we don’t necessarily need that for our gradle build. If we only have the inpath dependency the gradle eclipse plugin will miss it, so in Eclipse we also need to add the upstream project as a required project in the Java Build Path, like so:


Export exclusions

By default, adding the AspectJ nature to an Eclipse project causes it to export the AspectJ runtime (aspectjrt-x.x.x.jar). As all three of these projects are AspectJ projects, we end up with multiply defined runtimes, so we need to remove the runtime from the export list of the upstream projects.

Gradle is much better than Eclipse at dealing with complex dependency graphs. In particular, if an upstream project depends on an older version of a jar and a downstream project depends on a newer version of the same jar, the newer version will win. In Eclipse, both jars will be included in the classpath, with all the corresponding odd behaviour. So you might also need to tweak the export exclusions to avoid these situations.

Run configuration

Once you’ve cleaned up the exports from upstream projects, Eclipse will cheerfully ignore your exclusions when creating run or debug configurations, for example when running a JUnit test. This seems to be a legacy behaviour that has been kept for backward compatibility, but fortunately you can change it at a global level in the Eclipse preferences:


Make sure the last item, “only include exported classpath entries when launching”, is checked. Note that this applies to Run configurations as well, not just Debug configurations.


The manual Eclipse configuration needs to be redone whenever you do a gradle cleanEclipse eclipse, but usually not after just a plain gradle eclipse. It only takes a few minutes to redo from scratch, but it can be a hassle if you forget a step. Hence this blog post.