Lombok Is Still Relevant in the Age of Java Records | Hacker News Reader

Lombok Is Still Relevant in the Age of Java Records

swaranga.dev

19 pointsswaranga25 comments

Lombok was never relevant, and using Jackson’s or other frameworks’ undesirable runtime sorcery does not make Lombok any more sound.

Adding a pile of annotations throughout your codebase, often five stacked on top of one another, which generate behavior that is not locally visible, was never a sane trade-off for saving a little boilerplate.

You don't see assembly or byte code either. That doesn't make your high level language insane. I don't need simple expected behaviors visible "locally" other than that annotation.

Exactly my thoughts. The problem that Lombok tries to solve in obscure ways, can be solved much simpler: with a code generator program. We wrote our own before Lombok was a thing. And in times of AI agents it's even more obsolete now.

Also the argument about Jackson and reflection magic is no longer true since JDK21. All Json frameworks now require explicit default constructors otherwise the throw RuntimeExceptions.

Quality of life libraries like Lombok (or my library https://github.com/Randgalt/record-builder) are now anachronisms. Agents don’t need libraries to avoid writing getters, setters, etc. Lombok et al are for humans and the days of human coding are ending, sadly.

With that logic every library ever created is now anachronism. Agent can just always code using standard library of the programming language.

Maybe that's not a bad idea.

No, it's a bad idea.

Coding agents are not omniscient gods. Cognitive complexity of code is still a thing for LLMs. And every line of code that the LLM writes is still a line that needs maintenance, and has bugs.

Software engineering rules still apply. Coding agents move the needle somewhat on "what can be maintained by us vs. what someone else can maintain" but not _that_ far. And the same "Don't maintain it if you don't have to" approach still applies. More code to maintain means bigger context required, which means the agent burns more tokens to do a task. More context also means the agent makes more mistakes and adds more bugs.

Abstractions are still a good idea. Handing off maintenance through abstractions is still a good idea. Good software design is still a good idea.

Lots to agree; I am certainly feeling it these days. I used to be excited for new language features (records, pattern matching) but I was looking at the recently posted Devoxx conference talks on Youtube and for every one of these, I was thinking "what's the point? The code will be written by an agent anyway".

they don't need it, but it surely saves some tokens since it just expresses the intention of the code in a denser way.

agents make dealing with boilerplate easier, but that doesn't change that boilerplate itself is just bad

Lombok offers more than data classes, so Java records obviously cannot replace it completely. However, @RequiredArgsConstructor makes the code harder to understand. I prefer a visible constructor that shows which parameters a class needs. With modern tools like IntelliJ IDEA, generating (and updating) a constructor is easy, and the visual noise can be reduced by folding the constructor when it is of no interest.

Annotations like @RequiredArgsConstructor also encourage poor style, because there is no room for validation inside the constructor. At most, @NonNull adds null checks, and that is all. Lombok still offers many annotations that promote bad practice or have been superseded by the language itself, e.g. @Setter (mutability without protecting invariants), @Value (records) or @Cleanup (try-with-resources).

@Slf4j can easily be replaced by a single line of code (with the Log4j 2 API, even without specifying the class name).

Lombok's builders are actually useful, since Java has no named parameters with default values (as Kotlin does).

Regarding the "Dark Magic" section: just because other frameworks like Hibernate apply their own flavour of dark magic doesn't make it any better. Such magic should be kept out of the functional core of application code. The more magic is applied, the more problems can occur (e.g., the correct order in which tools apply their magic). This is essentially accidental complexity introduced to improve developer experience, but in the age of AI this may be the wrong optimization.

If you write modern Java, Lombok really doesn't add much.

I’ve always been curious as to why Indonesia islands have been the naming convention for this sort of software for a long time.

It’s also funny because there is true irl “dark magic” for Java, Lombok and Bali.

Also surprised there isn’t much mention of Bali in general.

Well, cos Java, while they named it for coffee, hence coffee related projects (Correto, Caffeine, and of course, all them goddamned Spring Beans) also being the name of the most densely populated island of Indonesia lead to related projects being named in an Indonesian theme like, obviously, Lombok, but Batik (an Indonesian tapestry form), Jakarta (largest city in Indonesia and on Java), IBM Semeru (the highest mountain on Java) , Apache Wayang (wayang is a traditional form of theatre in Indonesia and Malaysia), Project Sumatra etc. etc. etc.

and don't forget projects like eclipse and an internal ibm effort called sunset that should give an idea of what part of their points were.

Lombok fucking sucks

@requiredargs sucks, if you rearrange the order of two fields with the same type on a class you invisibly break the code. If you have multiple constructors (requiredargs, allargs) it makes tracing how they’re used using the built in tools of your IDE impossible

@builder fucking sucks, if there’s non-nullable fields and you don’t set them, at best you get a runtime exception. Builder pattern should take non-null args explicitly in the builder() method so when you add a new required field it doesn’t invisibly break code 8 modules away

Only good thing is indeed the log annotation, and to some degree @getter @setter, big whoop

> tracing how they’re used using the built in tools of your IDE impossible

It is possible but requires more key strokes. It is annoying, but possible.

Can you elaborate?

To be clear, I know how to look up where the class is used, and i know how to look up where constructors (note, plural) for the class is being used, but I have not found a reliable way to find where a specific constructor is being used if the class has multiple

I use Idea with eclipse shortcuts. I have lombok plugin.

Ctrl-O for a popup window of all methods. The lombok generated constructor is there. Highlight it and then shortcut for call hierarchy. Ctrl-h or ctrl-alt-h I am not sure now.

If you don't like it then don't use it and carry on. No need to litter the world with such negativity.

There is a litany of expensive consultants coming in and shitting up code bases worldwide with cargo-culty supposed 'best practices' like Lombok. It is good to call it out.

I used to be the biggest lombok fan. I appreciate what they are trying to solve. I just have issue with what happens under the hood.

This article does less to convince me that Lombok is worthwhile and more that Java (the language, not the JVM) is not.

Modern Java is bloody great. Lombok is, IMO, an artefact of the years of Sun neglect of Java the language, a workaround.

And I say this as someone who has been writing Python for a living for the past 4 years who rather misses Java and the ecosystem.

Strange, Why is Java not relevant? its just a language with a massive 3rd party oss libraries and frameworks

It's a language that tries to be everything but is at its heart Enterprise software.

e.g. poor support, or late support for

- JWT/Swing desktop UIs

- Web technologies (it used to have a built in JS engine, competing standards, servlets, jsps, jstl, portlets)

- Image processing (ImageIO is limited, Image and BufferedImage were slow)

- Native interop (overlapping / competing standards)

- RPC (CORBA, Jini...)

- Mobile variants (J2ME, Java Profile Variants, Embedded Java, Java card)

- Threads, Concurrency, native threads (confusing so many re-implementations)

- Delegates, sorry I mean arrow functions, oops no I mean lambdas. The features Sun said should not be in the language for years then back pedalled once it realised the foot gun calling out Microsoft for them.

So many attempts at relevance then abandoned, left in the language as cruft, or just ideas that were vehemently not Java, shoe horned in.

And they still don't have the Elvis operator, not for lack of trying though, they do have the abomination Optional instead though, but best practice says DON'T use that for arguments, just return types (but the language permits it anyway).

For newbies, Python is better, Typescript is more accessible for web or serverless, Rust for native...

And man is nothing more than a monkey who no longer lives in a tree.

Reply on news.ycombinator.com