Beliebte Suchanfragen
|
//

Project Lombok – Cool, but too much Magic?

29.9.2009 | 2 minutes of reading time

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

For 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?

|

share post

//

More articles in this subject area

Discover exciting further topics and let the codecentric world inspire you.

//

Gemeinsam bessere Projekte umsetzen.

Wir helfen deinem Unternehmen.

Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.

Hilf uns, noch besser zu werden.

Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.