Lombok — the good and the bad

Lombok — What’s all the fuss about?

Ricardo Espírito Santo
5 min readNov 28, 2016

--

So the project is no longer news to anyone. It’s been there for a while now and it has been discussed till exhaustion.

I feel that a few clarifications are in order.

Two inches deep into the controversy and you find one of the project co-founders — Reinier Zwitserloot saying:

It’s a total hack. Using non-public API. Presumptuous casting (…) If you could do what lombok does with standard API, I would have done it that way, but
you can’t.

Well, let us put things into perspective. This was written in August 2009, seven years ago, and since then, a lot of things have changed and the project has not yet been abandoned. So is it really a hack after all?

How does it all work?

Well, there’s this thing called Annotation processing that … you guessed it processes annotations.

These annotations are processed at compile time. They instruct the compiler to generate more java code, this code, will in turn, be itself compiled as well.

Oracle tells us that it is easier to extend AbstractProcessor when writing an annotation processor. If we do that we end up with one method that we must override:

AnnotationProcessorHelloWorld.process method

This method is where the magic happens. It receives the annotations it may wish to process and the roundEnv which provide clues regarding the current and prior round. The boolean return type indicates whether or not this processor is ‘claiming’ to have fully processed the given annotations or if they should be left for the next round to be further processed.

So what else can we override from this class?

This simple method indicates what options are allowed in our annotation.

getSupportedAnnotationTypes is where we define what fully qualified annotation class names we wish to register as a processor for.

If your annotation is going to support the latest java source code level then you can specify that here:

Otherwise it will stick with version 6. Checkout: javax.lang.model.SourceVersion

The init method substitutes the constructor, which has to be an empty one, and allows the developer some insight into ProcessingEnvironment.

And finally getCompletions allows us to provide some Completion as text to be filled in as part of the annotation.

What happens next ?

Your new annotation processor will run in its own JVM and will produce the source code you tell it to. Simple, no?

So why the big fuss?

To get to the bottom of it we have to analyse the way lombok is implemented. For the most of it there isn’t a lot to say about the code, its architecture or concepts behind it.

There is, however, this bit … over which, arguably, the whole logic is laid that seems to stir the most emotions: A class named: JavacAnnotationHandler that uses internal java stuff. Namely:

Importing JCAnnotation

and:

Using JCAnnotation abstract method

Since packages like com.sun.* should not be used directly because they do not belong to the standard java API and are therefore private. Any breaking change that oracle decides to perform could, potentially, break this project if one was to upgrade their java version and lombok hadn’t yet caught up to it…

Final thoughts

Everyone writes code differently, everyone is very passionate about what constitutes code quality and everyone is very eager to give their own opinion [exhibit 1, and exhibit 2].

But, as a great engineer, I once had the opportunity to work with, said:

Lombok is like parsley — I can either take it or leave it …

I never realised if he fully meant for the entire weight I’m about to put on the interpretation but here it goes:

1 — Clever choice of words since Lombok is the Javanese word for chilli pepper and by using ‘parsley’ here, he is subtly diffusing the whole thing…

2 — It is in fact a complete matter of choice, working on a project with it or without it should make or break anything.

To me, it almost sounds like the java community cannot leave with or without it… It has been 7 years since the project was firstly release, lots of articles have complained about it and not a lot that can be done about its ill ways in the implementation chapter but, nevertheless, 7 years have gone by and there is still quite a lot of interest in it, it still sparks emotions when it is mentioned. Isn’t that more that can be said about all the standard, super correct, law abiding frameworks that have since came and gone?

I have also asked Mr Reinier Zwitserloot if he would still maintain his initial opinion regarding the article and these were his words:

It’s still a hack, in the sense that we are using API that isn’t public and hasn’t been endorsed as stable.

Given that lombok today works in all the places it has worked before, and in a lot more since we started, suggests that, as far as hacks go, it’s a pretty stable one.

What are your thoughts? Are you using, have you used, have you ever had any issues using lombok? Let us know!

--

--

Ricardo Espírito Santo

I’ve been working as a hands on software developer for a while and am still as excited about technology as on day one