Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »


This text here is based on ideas from Jochen Theodorou (see chitchat-with-groovy-compiler and ast-macros-and-mixins)

Right now, there is no good macro preprocessor for Java. Annotations somehow come close but they don't really fit the bill. Sun says: "Annotations shouldn't change the semantics of code" and "they mustn't make the compile fail".

Well, how about @Override (which makes the compile fail if the method is deleted in the parent class) or annotations added or OR Mappers which change the code a lot. They just don't do it at compile time but at runtime, so there is no way to see what is actually happening: When the error happens, the code which is executed can be completely different than what you see in the source. Even decompiling the class file will not help anymore because the information isn't there, yet. It's only added when the classloader reads the file.

So from a certain point of view, Sun's solution is the worst of all worlds: Your code is changed at a point in time when you can't see it anymore and you cannot move the modification in the compile cycle because the API simple doesn't allow it.

The Goal

To know where you want to go, you must have a goal. The goal here is to reduce the amount of code to write for a certain feature. Specifically, the idea is to be able to move common, repeated code into a single place and be able to reference it easily.

The code must be more flexible than a method call and easier to manage than cut&paste.

Example 1: Bound Properties

A bound property in a Java bean is a field which sends notifications to listeners when it is changed. This means it is made up of these parts:

  • There is a list of listeners who are interested in changes
  • The field itself
  • Methods to add and remove listeners
  • Setter code which changes the value and notifies the listeners if the value has changed

Example 2: Merge Java and SQL

OR Mappers will only get you so far. While they will solve many or all problems, they also introduce new ones:

  • You have to learn to use the mapper
  • You must still understand how a database works
  • The mapper will try to connect the Java semantics to the Database semantics. This is not always straightforward. For example, a table might define a non-unique primary key. There is no way to map this to a Java map where primary keys must be unique or you will overwrite objects.
  • When a mapper doesn't support a specific corner case, you're in trouble. Mappers are often quite monolithic and they shove their tendrils in many places. Usually, you can't split it apart, injecting your own code in certain places.

So what do we expect from AST Macros in this case?

  • They shouldn't get in the way of the developer. If she choses to use an OR Mapper, she should be free to do so.
  • It should help to manage all the cases which the OR Mapper doesn't handle well.
  • It should give aid to interface the Groovy code with the OR Mapper.
  • It should allow to write code which directly interfaces the DB (for example, when you have to execute some special SQL which the OR Mapper simply can't do).

Some simple examples:

  • counting rows
  • loading objects from a DB


Before we look at solutions, let's look at what the code ought to do in the end.

Example 1: Bound Properties

should become


  • When using code completion, the additional fields and methods should be visible.
  • The added code should be lean and fast
  • It should not get in the way of existing user code, for example, it should be possible to define a custom setter which gets wrapped by the code above
  • If a custom setter exists, it should be possible to invoke it before the comparison (so you can define setters which convert the value before assigning it)

This leads to a couple of demands which an AST Macro Processor (AMP) must met:

  • It must be able to see all fields and methods, no matter if the user supplied them or an AMP added them.
  • It must be able to add new methods and fields and static code to an existing class and presumably also to classes created by an AMP
  • It must be able to reorder source code or at least AST Nodes.

In a perfect world, an AMP should be able to modify the code on a source level and pass it back to an IDE, for example, so that I can see (and debug) what is actually compiled (instead of only seeing the Annotation).

Example 2: Merge Java and SQL

TODO This section will be written when the discussion about Example 1 has stopped.

  • No labels