Friday, September 4, 2009

Project lombok, interesting bean shortcuts with the annotation processor

I came across a mention of project lombok recently whilst looking for something else. It is a combination of annotations and annotation processors to make bean programming more declarative. For the purposes of this blog I am going to use a quick example using the @Data annotation. So for this simple class the attention of the @Data annotation will at compile time add in getters/settings equals/hashCode and a nice toString implementation.

import lombok.Data;

public class DataExample {
   private String name;
   private double score;
   private String tags[];

Now lombok has integration with Eclipse and javac, since we are using JDeveloper I am stuck with the latter. In theory all you need to do is to make sure that JDeveloper compiles with "javac" with the lombok.jar on your classpath. It turns out that at least in the more recent versions of JDeveloper we use the compiler API directly which doesn't appear to properly invoke the annotation processors in the library. (Look under lombok.jar!/META-INF/services to see how this is wired up) The trick is to configure JDeveloper to run javac "out of process":

Now before you compile JDeveloper might complain that it can't find any of the new methods; but as soon as the classpath is populated even code insight works correctly (although not inside of the DataElement class):

Using the above data you can see how the toString() method is puts together some nice tidy output:

DataExample(name=Bob, score=4.0, tags=[Fun, Tall])

I wonder if the ADF team could use something similar to reduce the amount of boilerplate code that they have to generate. Also with a little bit of work you could get far cleaner JAXB and EJB artifacts. It would also be good if this project was extended to support bound attributes transparently and perhaps create a builder which always takes far too much time in my book.


Reinier Zwitserloot said...

Huh - that's a amazing. The big 3 (Eclipse, Netbeans, IntelliJ IDEA) never look at class files if they also have source files, and never invoke annotation processors when parsing source files for e.g. method names, so lombok is hopeless on all three without plugins (like we have for eclipse).

Do you happen to know if JDeveloper's internal parser (which it is evidently using to figure out if a method call to a local method should be underlined with: "Method doesn't exist", as you're running into with lombok's generated getters) is javac-based? If so, fixing that aspect of it with an agent shouldn't be to too much effort.

--Reinier Zwitserloot (project lombok co-author)

Gerard Davison said...


No the internal java model doesn't use javac. It just defaults to reading .class files as the source of truth which is useful in this case.

If you "clean" the project you get the nasty read underlining back as it has to fall back to using source files instead. I think I was just lucky that it works this way.


jambay said...

Gerard, if you haven't listened yet, you might enjoy the Java Posse discussion of Lamboch.

Gerard Davison said...


Thanks, just listening to it now I am back from my holiday...