[buremba]

While I tried to use Lombok in Java 8, it never felt safe. Even if I enabled the integration with the IDE, it magically patches my code under the hood so it wasn't easy for me to catch the bugs introduced by Lombok.

> There is little gotcha when using Java’s try-with-resource syntax. The resource has to implement AutoCloseable interface, so the compiler can use void close() method for closing a resource. Lombok’s @Cleanup, it doesn’t have to implement this interface. The resource just needs to have some closing method which by default is void close() (but you can specify your own method name responsible for closing resource).

Specifically, I don't agree with this approach in a compiled language like Java. We need to have a standard writing code in Java and AutoCloseable is the way to go. If the library doesn't support it, just create a proxy class and implement the interface there. It may be a bit verbose (we switched to Kotlin later on) but it will be much easier to catch the bugs. I don't want to spend 4 hours trying to find the root cause of a strange bug in favor of writing less code.

[jillesvangurp]

I used Lombok back in the day (never by choice). It's somewhat useful but I never really liked code generation and always felt it's a bit of a kludge and it indeed confused the hell out of intellij regularly (which is not that hard, it gets confused all the time). It's syntactic sugar. A bit of a stop gap to make Java look a bit more like several other decent languages out there.

Kotlin is indeed far superior and an extremely easy drop in solution on pretty much any Java project. A lot of what Lombok tries to achieve via code generation triggered by annotations is just built-in to Kotlin. E.g. a large part of what Lombok does is making java beans less painful by generating setters/getters and lots of other stuff. That's useful. However, Kotlin's data classes are way better.

For things that are Closable/Autoclosable, Kotlin injects a use extension function that takes a block where you use the resource and it cleans up after you. You just do a stream.use {...} and it does the right things. Kotlin adds tons of useful stuff like this to existing Java APIs.

Whether you use Java or Kotlin, any half decent static code analysis tool should be able to help you spot shoddy resource handling. Same for Kotlin; it has a lot of this built into the compiler. For Java, use spotbugs or similar. IMHO that's not optional.

[srazzaque]

Agreed - lombok is a kludge for language features, but back when it was big there weren't a lot of alternatives beyond switching to an entirely new language and stack (a tough thing to sell in large enterprise).

Regarding IDE support - I was once on a project using Lombok where some developers used Eclipse and others used IntelliJ. The Eclipse devs wanted to use this new @Builder annotation, which didn't work on IntelliJ but worked fine on Eclipse - for interesting reasons.

I attempted to patch the IntelliJ Lombok plugin to support @Builder - but gave up on it for reasons of time, priority and the fact that I wasn't certain it would work as Lombok continued to change. Also this was an experimental feature at the time that wasn't even certain to become mainline. I learnt a bit in the process.

Lombok works by passing certain switches as arguments to javac, which alters the class files that it writes out based on the annotations. It "confused the hell out of IntelliJ", because IntelliJ's intellisense/auto-complete plugin ecosystem works as so: IntelliJ exposes AST _from source_ to plugins, like the Lombok plugin, which hook in and let IntelliJ know, for instance, there's another method here due to this annotation. So it's constant effort to ensure the plugin's injections line up with what the compiler is actually spitting out.

Eclipse on the other hand is always aligned. I can only infer that it generates its autocompletion etc from the _compiler's output_. So whatever version of Lombok you're using, the autocompletion features will always be aligned.

[dehrmann]

I've used a few pojo-gen libraries, but they've never had good integrations or workflows with IDEs, and they usually led to a flakier build. Editing the definition file was never as good as editing a real class.

[zaphirplane]

FWIW Lombok enhances byte code, I don’t think it does code generation. Code generation is awesome specially when it works ;)

[erik_seaberg]

I don't know whether Lombok routinely generates source or bytecode, but its “delombok” command can definitely generate the equivalent Java boilerplate for whatever you use.