Overview

Project Lombok – Cool, but too much Magic?

1 Comment

Andreas pointed me at a nice library, lombok. It enhances Java compilation so that classes need less clutter to work.

Project LombokFor me, the features are awesome. Just by adding @Data to a class, it will generate all the getters and setters, toString() and the hashCode() and equals() methods. This is pretty much as in groovy the magic accessors. I like that. Because I can focus on the important stuff, rather than scrolling through hundreds of clutter lines. I also like that nobody plays around with my getters and setters and introduces side effects. It also fits to agile process: Eliminate muda.

I really like @SneakyThrows because i hate the UnsupportedEncodingException whenever if specify “UTF-8” which really never ever can happen (as long as the parameter passed into is a constant, not a dynamic param).

I also like how this is implemented: lombok hooks into the Java compilation and just generates code for the appropriate annotations. The Eclipse plugin takes care that navigation through code does not suffer.

It is just cool and for sure will grow to include more useful featues.

But the downside of this is that we introduce (more) magic. Magic, which is hard to predict. I feel that the learning curve for the average developer is too steep, so in the end, the gain, which is actually just a bit cleaner code, is not really paid off when there is confusion around.

Also think of maintenance: You now would use lombok, but in 2 years it is no longer cool and the project is dead (which I don’t hope; just assume). When now an additional year later somebody has to work with this code, the “clean” code strikes back, and the maintainer wonders where the getters and setters are.

Sidenote on Getters and Setters: I believe you actually do not need them, and most often just generate because Framework X requires them. I think Getters and Setters should not introduce side effects and just set the value (that is done by lombok as well). But why not just make the field public? There is no added value in having stupid Getters and Setters. You should have domain methods manipulating internal data. Thats it, no Lombok and no boilerplate code required at all ­čÖé

It is a nice toy for the experienced programmer. And its powerful. I certainly will use it for private projects.

What do you think about the “value / confusion” ratio? Is the ratio constant? Meaning valuable libraries cause always a linear amount of confusion?

Kommentare

  • Morten Christensen

    I also looked at Project Lombok but deemed it too risky to use (f.x. there are issues with the latest JDK). I also found the customisation features lacking, so I just released my own open source tool for generating java value objects that used 100% standard java features and is extremely customisable. You can check it out at “http://valjogen.41concepts.com”. Let me know what you think?

Comment

Your email address will not be published. Required fields are marked *