While I can understand why somebody would want to use Lombok, this is actually very misguided.

If you want to program in better language, just go and use better language.

The most important strength of Java and basically the only reason it is being used is that the code is simple to understand (simplistic!), everything is easily trace-able and debuggable and that you get fantastic tools that know everything about code and can provide you safe operations on huge code bases (refactoring, finding usages, tracing and understanding code paths, etc.)

Lombok and new Java features decrease reliability of tools removing Java's biggest strength.

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.

Relative to toponym: a few years ago I got bitten by an unidentified creature on the beach in Lombok and nearly died of asphyxiation due to a severe histamine reaction and the length of time it took to get to a hospital. Really severe .. said my goodbyes to my wife. Never had anything similar in life before or since. Luckily we did reach hospital with a couple of minutes to spare and the local hospital sorted it pronto (oxygen and loads of antihistimines). The cost was minimal. Life really has its ups and downs... too many to care about Java libraries :)

So I've my self used Lombok but I've been using Kotlin lately. IMHO Kotlin if far far superior in terms of how it provides appropriate constructs that are patches to a stale language (hopefully new release cycle fixes it).

So far I've observed with libraries like Lombok there is a smaller community (compared to language community) that vets the idea; and the features are opinionated to that particular community. Which results into fragmentation; just as example https://immutables.github.io/ and https://github.com/google/auto are two libraries providing features like factories and immutable value classes. Then you get articles like https://codeburst.io/lombok-autovalue-and-immutables-or-how-... for improving your code.

This in my opinion doesn't hurt as long as you are a small company. But when your code is going to be used across teams with different opinions, and language doesn't enforce a single way to define construct these kind of byte-code mangling ideas fall apart. I've personally people complain about Lombok and they hate it every bit. Doing these constructs at language level removes debate, and unifies how people in larger community. I hope newer versions of Java move fast enough to make something simple like `@Cleanup` a thing of past. I will highly encourage everyone to try Kotlin too; it's almost transparent drop-in with better syntax.

The irony of people telling me that they don't appreciate Spring or Hibernate for the magic behind the annotations that they don't understand, to then turn around and drag in Lombok. Also, if you are telling me you don't like to write getters and setters, does that mean you are not using an IDE? _Sure_, it's a little cumbersome to write them, but not a lot?

Lombok certainly saved my wrists and hands from repetitive stress injury over the years. Manually typing “effective java chapter 1” immutable object implementations can be truly excruciating.

So you introduce a new library that does "magic" instead of using one more line? To me this is the opposite of good code. Let alone that the given example would probably live in some library code anyway.

There is a problem with JaCoCo, a Java code coverage utility, and try-with-resources. It looks like the try-with-resources creates byte code branches that are unreachable. In the JaCoCo report the try-with-resources line shows up with 4 or 8 branches (I forget which) and most of them are not reachable. That is to say, no matter what kind of unit tests you create (essentially there are two, a test where the code throws and a test where the code does not throw) you can not hit all the possible branches that JaCoCo detects.

This caused a problem for me because we would write very lean code with low cyclomatic complexity and having these missed branches would screw up our code coverage numbers, causing us to miss our standards. I would just do it the old way, with the finally. I wish I knew about this @CleanUp. For some reason a lot of code i am writing nowadays does not have me messing with streams directly, but when it comes up again I will use this annotation.

    OutputStream out = new BarOutputStream();
    in.transferTo(out);
    if (out != null) ...

Can someone explain how `out` could possibly be null here?

I've had better luck with patterns that take lambdas (and internally do the try-close) because they're impossible for users to screw up.

I was really hoping this was about the Indonesian island

I used Lombok many years ago, but stopped. Modern Lompoc, with tools like delomboc to generate plain Java source code, and better tooling support beyond Eclipse makes Lompoc look pretty good now (if I still used Java). Cool project.

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.