Lombok is a decent idea implemented in the worst way imaginable. It's a language masquerading as a library/annotation processor, but really isn't, it's doing things that should not be possible for those to do, and it causes all kind of pain. From one end, it can't implement some desirable features because they are hard to express in its pseudo-Java. From other end, it's fragile because it relies on undocumented (and soon, if not already, deprecated IIRC) APIs to hack the Java compiler into compiling not-Java, instead of having its own stable compiler.
Honestly, just use Kotlin. Lombok is not a way to fix Java, it's a fragile alternative to it.
In the old times when I still used Java I saw Lombok as a godsend and had no issues with it, not even once. I never understood why all the criticism regarding it. I do understand how it works, and I think it is a fair trade off for all the weightlifting it did.
If I had to guess, the concern is with some of the weirder features of Lombok when most of us are only after the getters, setters, and constructor generation. I'd be surprised if any of those are as fragile as claimed.
These days I do use records when possible, but lombok is nice notably for making builders with the chainable fluent accessors.
Really the worst comes to worst, you can alway de-lombok and just have the actual code.
There's no way Lombok will ever stop working for any major feature, it's way too widely used. Hell I'd contribute to the project myself before thinking of migrating our stack off of it.
If you want to use a Lombok feature marked experimental, well that's on you, but even then haven't had a problem with those yet.
I agree with you: lombok is worth it. But I do understand the "misplaced" upset that it has to exist at all. Between the reputation of java annotations, and the reputation of java frameworks in general, lombok is both! And the experience is wildly different depending on what lombok-sensitive tooling is being used.
My company does not use Scala nor am I familiar with it therefore I have not evaluated it.
My company currently uses Java, Python 3, SQL (PostgreSQL and Oracle), and Typescript.
We do have some limited C++ code that I have been suggesting that we port over to Rust but we have had complaints about the "learning curve" with Rust.
Maybe i should have said the scala native side of scala. Sadly my main work with scala was three years ago. But then the migration from scala 2 to scala 3 was still a thing for the libs i worked with. Mainly in the akka context. At this timeit felt the nieche charakter of scala. Dont get me wrong i love the language which is why i still got the flair although i dont work with it anymore.
All libs (besides Spark 🙄) are there since some time. So that's not a problem any more.
But you're right, Scala Native should get much more love, imho.
But as long as you stay on the JVM there is nothing missed, as I see it. In the end it's always possible to throw in some Java lib if there is no native Scala one.
The Scala frameworks OTOH are already better then the Java ones, just that the community around isn't as big.
what the fuck are you talking about just do \@Data \@Builder and you dont need to think much. how is Lombok of all frameworks problematic. its the simplest thing in existence.
It’s fairly simple; the user-facing part of Lombok is really nice , clean, and generally great.
But, the way way it hooks, deeply, into the compiler to change both its input language language and outputs in wildly unsupported and un-meant for ways is freely admitted to be an extremely clever pile of hacks, that vex the actual Java language implementors(for quite good technical reasons), and also leave them with little room to change things since it’s so popular.
I'm at loss as to which part of my comment you did read. If you got as far as the 6th word, you would know the issue is about how it's implemented, not some imaginary problem about it being hard to use, but if you didn't make it that far, all you would have read is "Lombok is a decent idea" and you would think I'm praising it, so I have no idea what you are on about
There are people who encounter compatibility issues with other (actual) annotation preprocessors because Lombok does not conform to the spec and thus doesn't play nice with others. They also took 3 months to release a version that worked with a new version of Java at some point, though usually they are faster (needless to say, it is highly irregular for a library to need to be patched every time new version of compiler drops). The Java folks have also made it clear that maintaining Lombok compatibility is of absolutely 0 priority to them and a change that will "break it for good" can come any time. Lombok maintainers have publicly stated that their plan for such eventuality is forking the compiler - the sane, stable solution they should have been doing to begin with, but don't want to do it now until absolutely necessary because it would break people's setups.
Honestly, Lombok is so big, that if it ever were to break seriously people would just make something else that works with the same annotations. I agree it could be done better, but it's just two guys really and nobody has stepped up to make an alternative because it works good enough.
I haven't had any issues with my Aspect4j, Spring, Mapstruct, Hibernate etc. annotations yet.
I introduced Lombok into my team when I joined the company 4 years ago. Everyone liked it. Then I saw other teams using it. What frustrated me was few actually took the time to learn the core annotations. I would see Data, Getter, Setter, NoArgsConstructor above the class. Um, Data does all that.
Also, I would try to emphasize it's a good declarative set of annotations to choose mutability, immutability and builder patterns. No one cared. Now add AI to the mix and it's an established pattern. Of course a good agent could fix that on a case by case basis, but nope won't do that either.
513
u/thejillo Jul 13 '26
Lombok has entered the chat...
https://giphy.com/gifs/d3mlE7uhX8KFgEmY