What do I think about Lombok?

Tags:

What do I think about Lombok?

I think it’s a nice island, and I wish to visit it one day.

What do I think about Project Lombok?

Well, I’ve been asked this question so many times, I’ve decided to write this post. Its main purpose is to be able to paste the link and back up, because the (yet another) discussion might be so intensive, that fists will be shaken and heads will roll… There are three assumptions here:

  • These are my opinions. You may or may not like them. It’s up to you and I can’t help it. If you find familiarising with someone’s opinions disturbing, maybe it’s time to stop reading. This includes (but it’s not limited to) all magnificent souls behind Project Lombok.
  • In Poland, we say ‘only a cow doesn’t change its mind’, and since I don’t identify myself as a cow, my opinions may change. E.g., because your read them and convinced me I was wrong. Trust me, I like to be enlightened that I was wrong. I find this as an absolute foundation of scientific approach. Therefore, this entry is a subject to change without prior notice.
  • I’ll keep referring to “Project Lombok” as simply “Lombok”.

Where do I know Lombok from?

I first heard about Lombok during Hamlet D’Arcy’s talk, which AFAIR was in Cracow like 10 years ago or so, so it must have been GeeCON or 33rd Degree (now known as Devoxx Poland). More or less at the same time (or maybe a bit earlier) I started familiarising myself with Scala. Like, you know, case classes, generated accessors, @BeanProperty, and the like.

And I was impressed, that’s what I remember for sure. That in Java we can also have some trivia generated for us.

It took some time before I saw that in real production code. I saw it here and there, I used that in a few projects over few years, so now I dare to consider myself as an ordinary Java dev who saw how the tool performs in combat.

Tool? Not a lib?

Precisely. From my point of view Lombok is not exactly a library. I like the informal distinction between libraries and frameworks (which I think I’ve heard for the first time from Dr. Venkat Subramaniam) that relationship with a library is easier to break than with a framework, just as it’s easier to swap girlfriends than wives. In theory, we should be able to replace one library with another one, provided it’s doing more or less the same, especially when they implement the same interfaces (although being equally functional many times is enough). To some extent we can say that about e.g. Apache Commons and Google Guava, or some logging libraries. Frameworks OTOH are significantly different to get swapped or rid off, e.g. when was the last time when you replaced Spring Framework with Quarkus or Micronaut in a project with some history? Exactly, it’s also doable (like everything in IT, having enough time and money), but it’s not something we frequently do, because the thing leaked literally everywhere.

Many of us like to think that our external dependencies can only be libraries or frameworks. Quite like people years ago wanted mushrooms to be either animals or plants. World, I’m afraid, might not be that simple and because of that there’s not only fauna and flora around us, but fungi as well. (Guess what, now we have three more kingdoms.)

I think that Lombok, despite having some libraries' properties, is not strictly speaking a library. Can you name other two Java libraries which (make sure all are checked):

  • rely on (pre-)compiler’s plugins
  • aren’t easy to work with if you don’t have an IDE plugin installed
  • freakuently stop working with new releases of JDK, IDE, etc.
  • spread to all layers of your architecture?

That’s my point. I don’t know if the term “tool” is the best one, but since I don’t quite enjoy using “gizmo” or “wichajster”, let me use that term. We might come up with another one, if we find a better name. What I want to stress here, is that IMHO it’s not true to say ‘Lombok is (yet another) library’. Taking its prerequisites into account, and the effort to get rid of it from any mature project (I’m thinking about Testcontainers here ;-) ), it’s not that librarish at all, despite being an innocent single entry in your POM file.

Lombok is easy-peasy

Lombok might seem easy after you watch a demo or live coding session given by one of professional Developer Advocates. Little annotation here, another one there, et voilà, we saved a lot of key-strokes. Question is: what had we sacrificed to get this easiness?

  • Have you seen this demo opened by someone else in their IDE (even as source bundle for RTFM) without the IDE plugin?
  • Have you seen them carefully selecting versions of JDK, IDE, Lombok and Gradle to make sure the Demo Gods are satisfied?
  • Do you think anyone has tried to upgrade this little demo across these versions (well, if you wish, you can try to upgrade my little demo for records' torture to the newest Java and Lombok…))? Just instead of rolling it back before next talk?
  • Have you ever tried mixed build with other languages?

Lombok is darn hard and banned

‘We can’t allow Lombok, because new junior members constantly broke things by using @Data!’ Oh boy, how many times did I hear it? Now, my question is: how many times did your junior members broke things up because they clicked-this-then-that and generated incorrect equals or hashCode in IDE wizard? Or worse, added some fields but forgot to re-generate these methods? What if you’ll end-up with bugs due to default implementations in records? Will you keep blaming these other tools, instead of sheer human incompetence? What about universities/bootcamps/trainers, will you blame them for not teaching the absolute Java 101, that is: when, how and WHY write equals and hashCode?

Go Kotlin/Scala

Yeah, been there, saw that. I think we’re going back to the previous point, because (whether you like it or not) they’re still running on JVM. Besides, think of the codebase from company’s or manager’s point of view and stretch it to the total life span: employing decent Java developer might not be so easy. Do you think hiring Kotlin/Scala devs is easier or harder? Or do you really think doing such a drastic change like choosing a new language is justified, ‘because Lombok’? Don’t get me wrong, whenever I see point in going multi-lang projects I vote for that change, but software product is not only about choosing language or dependencies, there’s a bigger perspective in space-time.

Not worth the trouble

Could I answer in any other way than ‘it depends’? There are pros and cons for literally everything in IT (except “Hello World!"). So the answer, I think, is quite simple here: if you know the cost of using Lombok, and it’s significantly less than not using it, why not use it? After all, it’s just a tool. Question is: do you really know the cost of using Lombok in the very project you’re in? Not that ‘I suspect…’ or ‘I heard…’, or ‘Everyone knows …’ I mean the actual consequences.

Lombok is Lombok

It may sound trivial, but I really think Lombok is the one and only of its kind in Java ecosystem.

It’s powerful, but with power comes responsibility. There might be a reason why we don’t let our children drive monster trucks, or even our regular cars, and instead give them these little RC ones… It’s because a modern automobile is still a complicated piece of machinery even to drive, not to mention maintenance.

Lombok is not a toy, it’s a sophisticated tool, and as such should be used by qualified personnel to make sure it doesn’t do more harm than good. This is, I think, one of the biggest failures of our community: hiding complexity, so naive and junior souls can think ‘it just works’ or ‘it’s magic, don’t worry’. Due to all these single-use demos it looks innocent and always safe, but it’s not. In hands of untrained person it may turn into destruction tool sometimes.

How do I define trained person, when it comes to Lombok? Well, I see some stages:

  1. someone knows, that Lombok is cool,
  2. someone knows, that Lombok has documentation,
  3. someone read the documentation,
  4. someone understood the documentation,
  5. someone verified they understand the documentation by checking the “deLomboked” source code,
  6. someone verified they understand the documentation by checking the generated byte-code.

Why do I say about verifying using byte-code? Well, maybe because (surprise, surprise) what Lombok does is manipulating byte-code.

Road and cliffs

This is how I see Lombok. A very powerful (thus potentially dangerous) tool, which usage should be verified and approved by Stage 6 specialist, carefully comparing benefits to the cost, and constantly mentoring less experienced team members. Someone who knows by heart, that if they write @AnnotationA in position X, certain byte code will be generated and thus certain behaviour will kick in. And if the @AnnotationB will be used, or the @AnnotationA will receive a parameter, or will be moved to position Y, other things will happen. From that perspective Lombok is just a copy-and-paste thing. However, it takes effort to get there.

Beware of advisors, who tell you that you can take a nice, free and safe shortcut to avoid all bumps and efforts.

Picture by Dimitris Vetsikas.

​