I would strongly discourage against Lombok. As already stated it introduces a semi-Java language that brings in a lot of experimental stuff.

All of these will have to be evaluated and agreed on by your team-mates (for the love of god do not allow all annotations, some are pretty hairy) creating a lot of bikeshedding and non-productive hours.

The biggest drawback that I've found is the inability to coexist with Kotlin making migration almost a no-go for larger codebases. When you're eventually ready to try out Kotlin, you'll find yourself in a dead end and wish that you just used it from the beginning instead.

Nowadays I personally see all frameworks / libs that uses annotations as some kind of magic evil as you can most often get the same benefits using language constructs. No one said that it is forbidden to create immutable objects with public final fields if you just want to get rid of getters for the cases where you want to expose your inner fields. It's perfectly fine and you'll probably end up liking it. Same goes for DI which you really don't need Spring for.

Lombok is bad mainly because it does things by tweaking the compiler. It breaks so frequently with new versions of java that it's bonkers.

The other alternatives (AutoValue, Immutables) work with javac in a standards supported always compatible sort of way. Because, they just generate source code based on annotations. That means they'll be not only compatible with Java, but also things like Kotlin.

I do agree that a simple class with public final fields isn't a bad thing. However, a little bit more complex data class with equals/hashcode/tostring becomes a little bit more annoying to maintain. That is where these libraries have value add.

I used Lombok in many projects and I think it's important to not forget some points about it.

Lombok modifies the AST, which is afaik not covered by the language spec, because an annotation processor is not allowed to modify existing classes. This is a big hack that's not really supported somehow. But no judgement here.

This is also the reason (?) why you need special IDE plugins to work with Lombok. From my experience, occasionally there are subtle problems with the common IDEs, for example showing you red error messages even though the code compiles fine. There are many people out there that never had any of such problems, so many people will tell you there aren't any problems.

I experienced a hand full of cases where I used annotations like Builder, that resulted in compilation errors for the project. The error msg was cryptic and at the end I had to delombok (very nice feature!) the construct and generate the corresponding java source code. Again, there will be many people telling you there are no problems... which is true, until you know better.

All in all, I always have to ask the question, if Java as a language is not enough, why not instead take a look at other languages, for example Kotlin or Scala, that really take everything to the next level and give you a ton of additional benefits on top, for example Null safety or coroutines, data classes in Kotlin? Or the ability to write builder-like constructs just like named parameter usage or function chaining in all other places of your code?

If that's not really an option for you, I can recommend Lombok. Most of the time, it will work without any problems and it will probably solve what you think your problem is :)

I agree completely. lombok is, in effect, a dialect of Java and an odd one at that. For all its claims of removing boilerplate, etc. you end up with a bigger moral hazard in that all the ceremony is moved to opaque bespoke annotations that don't give much indication of what they're implying. At our company, we end up with model classes that look like this:

This is a worse experience. Forget one little thing in one of those lombok specific annotations and suddenly you've lost encapsulation and immutability without realizing it. Further, try using your IDE to find the usages of the getters/setters that are auto-generated.

First of all; it's your teams' choice to work the way you do. You don't have to specify field defaults; that's a choice. You don't have to use a builder, that's a choice. But it's still better than creating / generating all the getters, setters, builder and constructors yourself: that's also code you then have to test and maintain.

No, the outline view. Literally the 'view' (as in, window menu, the 'view' option) named 'Outline' (pick the one named 'Outline'). In this view, the generated getter is shown as one of the members. You can invoke 'find callers' from there.

For most lombok annotations, hitting the keyboard shortcut for 'find callers' on the annotation itself also works. For something like @Data which represents lots of generated methods you have to resort to the Outline view.

If you're working alone or on a very small project, and you have an eagerness to learn, then every additional feature that a product like this has is more money in your hand, and any of its sharp corners only sting temporarily until you learn them.

I believe that when working in a larger context, things are considerably different. Each rough edge and even each feature you didn't strictly need becomes a liability, just that much more burden for everyone on your team who is trying to understand and maintain code they didn't write. This is especially true of things like Lombok that use unusual extralinguistic mechanisms.

This is why we felt that there should be a tool for generating plain-old value objects (the kind that in the future will become Java "records") that was as simple, straightforward, and unconfigurable as possible, and worked as naturally as possible together with the Java language as it is designed today. We put our ideas through many rounds of very strict review, and in the end out popped AutoValue.

The basic idea is that you provide an abstract class, and the generator just implements it. I believe it's the lowest-magic solution possible to this problem (without sacrificing performance).

We are very happy with it inside our own company, where it has hundreds of thousands of usages. But yeah, this is a very different design center from Lombok, and even from Immutables, and may or may not be what you want!

I've brushed by a few projects which use Lombok, nothing in-depth; it seems practical to use an annotation or two rather than having to constantly define getters and setters. I would've considered using it if I were to start a new Java project however with the rise of Kotlin and auto-generated gets/sets it's redundant for me at least.

A past team I was on relied heavily on Immutables, and we really liked the shift to immutable value objects and builder-style object creation. May not be everyone's cup of tea, but having Immutable objects just removes a whole class of mutation-based errors.

Lombok is great too, just a different approach. It can be a bit fiddly with Intellij & the Lombok plugin, there are times where it just seems like it doesn't understand and won't navigate to the proper member. To be fair, it's been a while since I used it though, maybe it's better now.

I use AutoValue with AutoBuilder. This is very concise, readable, and simple. This works perfectly for most value objects that are immutable, e.g. internal to a class or a response holder.

I use JsonSchema2Pojo for APIs, where the object should be mutable and serializable. I use jOOQ for database access, which generates record classes.

AutoValue serves my purpose well enough that I never had a reason to try Immutables. I'm sure once Java adds records then I'll switch to that; hopefully there will be a builder syntax. I've heard mixed reviews of Lombok due to its compiler hacks, but never tried it either.

Thanks Kevin - Manes here. Would you consider incorporating something like AutoBuilder for convenience directly within AutoValue? I commonly don't need richly customized builders and when I do then I use AutoValue's syntax. Otherwise I almost always use an auto-generated builder as cleaner to read code, less boilerplate then writing it by hand, and clearer than factory methods. Its helped popularize AutoValue throughout our codebase.

Immutable: I found it a little bit clumsy. I personally do not like libraries that generate sources which should be used throughout your codebase.

Lombok: Lombok is great. It saves a lot of time and all Pojo classes or Hibernate entities, all classes are filling clean and tide. There are 2 main issues that I may highlight:

There are some conflicts when you are using aspectj and lombok dependencies in your project. I am sure there is a workaround and some libraries should be excluded, but it is not obvious and requires some time for googling.

As far as lombok modifies AST it has no precise error messaging. In case you misconfigured something you will not have clear error message pointing you to the place. I faced such errors when parent-child classes are using @Builder annotation.

But facing these issues is still worth using Lombok. Lombok is very useful. Wish they support custom annotations. For example, I would like to have @MyEntity annotation which will add set of Lombok annotations automatically.

The only people who complain about Lombok are the ones who can't be bothered to learn something new. And frankly if you can't 'understand' something as simple as the example I gave there I don't want to work with you.

cool, I want to work with people who follow solid and kiss only, you cant even imagine how much positions I rejected after I saw the code for first time.

Stupid plugins instead of hard but readable code, spaghetti code using terrible IDEs and again stupid plugins. When you will reach medior status you will know how much these fads suck when some junior like you comes on his first day to work and starts demanding or loudly complaining about some hipster bullshit.

Aside from his butthurt, he's right. Lombok is a terrible experience, good luck debugging things that are not there or working without plugin. You can justify Kotlin usage because it is a whole brand new world, and not a lipstick on a pig, like Lombok.

Lombok is a terrible experience, good luck debugging things that are not there or working without plugin.

I've literally never ran into problems with stuff Lombok generated. The biggest issue I had with it was that it blocked us from updating to Java 9 for much longer than it should have.

You can justify Kotlin usage because it is a whole brand new world, and not a lipstick on a pig, like Lombok.

I definitely agree that moving to Kotlin is a much better option, even if you only use it for DTO's. I managed to introduce it in my current project (probably my biggest achievement, I'm a big Kotlin fan) and people are generally enthusiastic about it.

In the previous project the non-technical CTO (yes really) was 'against' it for the sole reason that it was hard to find Java developers and harder to find Kotlin devs. A few Android contractors quit because they weren't allowed to use Kotlin.

The project before that was at a large bank with a lot of really conservative in-house devs who disliked even Java 8, Kotlin was an absolute no-go there.

Here in holland we have a saying "you have to row with the oars you've got"; getting Lombok into such a project is generally easier than getting Kotlin in.

Ill never understand people who reject Kotlin because "theres less demand". Ive written java code since 2009, and switching to kotlin in 2016 was the single greatest thing to happen to me. I could use all my old stuff (though I didnt because honestly I was garbage because I was like 13 at the time), but I could write something modern and beautiful with less lines of code. No more writing getters and setters for everything, no more typing `new` and using semicolons everwhere when theyre unnecessary. And using lambdas with receivers as well as using lambda notation outside of the parentheses for the last functional parameter looks SO good and feels so good.

Also from what I've gathered when talking to interviewers (I talk to them for the places I intern for just to kinda get an in on what they ask and why), and a lot of them ask how quick others are to adapt to a new language. And the team leads who I would so graciously buy coffee for would also note that the Java guys switched to writing effective kotlin code in around 2 weeks at worstt, a few days at the best. It just seems like a no brainer to at least allow some devs to use kotlin if they want to.

Ill never understand people who reject Kotlin because "theres less demand".

What I've seen so far is that there's basically two types of Java projects; the ones where there's a majority of conservative devs, and the ones where there's a majority of devs who are interested in new things.

For me a great indication is the Java version they're on: I don't do pre-Java-8 projects anymore. Not just because I'd miss my streams and lambda's so much, but also because these are generally dead sea projects. I know I'm generalising here, but I've seen a strong correlation.

So, in the game of chairs that is 'overcomplication', it is your opinion that lombok is the one that should take the axe, and not any of the others?

Well, that sounds like a rather arbitrary choice to me. Also, from experience I'd say that most java programmers don't use JavaEE, so you might want to update your commentary to include the caveat that you're commenting on lombok use specifically in combination with JavaEE.

As far as your second statement, now you're just being mean. Whether we are doing it 'for a portfolio' is, I guess, in the eye of the beholder, but perhaps with some context you'll understand why I feel rather insulted by this statement.

We're about to announce professional support for lombok via tidelift (they approached us, because we're one of the most popular java libraries used by their clients), we've been working on lombok for 10 years, and in those 10 years, both Roel and I (the main authors and creators of lombok) have held the same day-job for all those 10 years. Yes, lombok did get us a few major speaking engagements (devoxx and JavaLand in particular); for all of those we got free full passes to the conference but no further compensation (so, those cost us money; we had to pay for the trip and sleeping accomodations ourselves, not to mention no compensation for the extensive time we put into making these presentations).

Roel's employer probably did get some utility out of all of this; TOPdesk employs many java programmers and also sells to business that employ java programmers.

Mine, on the other hand? I doubt it. We are a small outfit that sells solely to dutch general practitioners. They'd be about as interested in java tooling as I'm interested in fly fishing.

Because others asked us to do it, we've introduced the possibility to donate to us (via patreon and business licenses). As you can see from our patreon page, this is most assuredly in no way or form adding up to anywhere near what we could have gotten, had we spent the time we spend on lombok on freelance projects.

That's to say: Lombok is a labour of love. It is a hobby. It better be, because it sure isn't paying any bills, not directly, and not indirectly either. Other than your comments, the rest of this reddit thread is fortunately very motivating.

Anyone who I work with that tells me they use java with lombok, I kindly introduce them to Kotlin because it looks much more natural to read, (personally) feels much more natural to use, and does what lombok does without all the annotations mucking up the screen. Plus its 100% interop with java so theres really no downside to using Kotlin instead of java+lombok.

Java always felt a bit wrong to me, and thats probably because its stuck 25 years in the past with their backwards compatibility policies. It just feels old, and lombok does try to bring some modern features in to Java but it does it in the wrong way. It looks kinda wrong, and its hard to debug because it does hacky stuff not according to spec to achieve what it does.

That's not to say lombok is unreadable, its just.. meh... but if you REALLY want to stick to the old ways with java and use hacky tricks to get what you could get with Kotlin, a more modern language and still 100% interoperable with java in case you have others who work in java or have some useful classes you dont want to rewrite.

I have used Lombok in development, but when it comes down to actually doing a release of code, it's just as easy to use eclipse to generate my get/set/toString methods. It's a little less confusing if someone else is looking at the code.

So do I, but when I receive a gRPC request or just a bunch of JSON, I usually pack this into a DTO and then have some sort of a layer which translates it into the model. This way the model is independent of the way the data is provided.

I love Lombok. Or, well, specific parts of it. I mostly use it for the incredibly convenient @Getter and @Setter annotations, plus @FieldDefaults and the annotations that make default constructors from the fields. Additionally, it provides the @Value annotation which seems to be the main purpose for Immutables and Autovalue (tbh I had never heard of either of those before reading your post).

I have shied away from using heavily experimental stuff like @ExtensionMethod though, as 1) it does not work properly on my IDE and 2) the semantics of which method is being used are a little janky.

Overall, I really love Lombok because it saves me from having to write so much boilerplate. I only wish it was easier to add your own annotations to it.

Exactly! It's not just readability (which IMHO is nonsense, I don't believe that is even an argument), Lombok classes are simply mch easier to maintain. It's pointless to even test getters/setters if you're letting Lombok handle them.

Because I sure as heck don't find the 'pure Java' one the be more readable. Not to mention the maintenance overhead; there is a whole class of bugs you get when adding fields to Pojo's and forgetting to add them to hashcode, equals or toString that you avoid when using Lombok.

To me when people say "it's harder to read" I hear "I never bothered to understand an industry standard tool".

Well, I'm an Android developer, so we're on a bit different tracks. When I was getting started there was an Android project with Lombok and it left bad taste in my mouth, I've been hating in since then, haha.

Yeah, definitely. I think it's great that in your space Google is pushing Kotlin so much. Even though I'm a "Java dev" according to LinkedIn I pretty much do everything with Kotlin nowadays. It's SO much nicer to write than Java. I'm actually giving a workshop on Kotlin this month for a group.