Provides short cuts for boilerplate Java code, such as replacing explicitly written getters and setters with field annotations. For example:
I have only come across this recently and my initial reaction is that I don't like it. Particularly because you lose all the help from your IDE where mine marks all fields as unused because there is no explicit code making use of them.
To gauge whether I'm just cynical and suspicious of all new things or not, what do you think of it?
I saw it being used once and had to get used to it but I never liked it, maybe it makes sense when you are using vim or something... I don't like when a class has hundreds of annotations, I find it more confusing. But I'm a noob without any experience so I might be wrong.
My first reaction was: What kind of Voodoo Black magic is this !!
After thinking for a while, I think that this looks good as a party trick, but I don't see much usage in actual client facing projects. Adding an external library just for Setters/Getters will take a lot of convincing for me. I saw a @Cleanup for InputStream, but again, this may not be of great use to me. Maybe I am just too old to learn new tricks.
Tim Moores wrote:I thought it was cool when I first saw a presentation on it (maybe 8 years ago), but looking at the demo now, my first thought is: Kotlin
This. Getting rid of Java boilerplate code is great. But there's only so far you can go within the confines of still using the Java language. Adopting Kotlin gives you all the Lombok benefits, plus much more.
I have some philosophical objections too, as far as how Lombok uses annotations within Java. They have side effects that contradict what we know (as Java programmers) about the class described in a file. It's one thing for an annotation processor to generate code for some other class. But Lombok is generating code in the same class described by the source file - code that clearly is not there in the original source. That's very counterintuitive for anyone not very familiar with Lombok.
The SneakyThrows feature strikes me as particularly objectionable. I suspect I will commit violence if anyone tries to use that on a project I'm attached to. Checked exceptions can now appear in contexts where the programmer's logic tells them they cannot appear - even in code that has nothing to do with Lombok. And further, the checked exception becomes uncatchable, except by a general catch Exception or catch Throwable.
Admittedly, the SneakyThrows is only possible because of a loophole brought into the language when they introduced generics. But Lombok's SneakyThrows is actively encouraging such immoral behavior.
Tim Cooke wrote:I have only come across this recently and my initial reaction is that I don't like it.
I've been encouraged in the past to use that magic myself, however, same as you - didn't like it at all and didn't use it. You can't validate parameters for setters, if you do want to validate them, you go back to a habitual Java's way, in which case you end up with hybrid code, which is dreadfully difficult to follow. If I'm lazy, I let IDE to generate stuff.