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.
I have the complete opposite point of view. I never used @Cleanup but at least the @Data annotation makes it much more readable IMO.
There is tons of boilerplate in a simple Java bean, so when you have 3 pages of getters/setters, equals, hashcode, toString etc... and someone introduces something hacky it doesn't jump out at you.
To be fair, it doesn't have to be a hack, but it's doing something weird that's unexpected.
Then if I use @Data and I still see a Getter/Setter defined it calls it to my attention since odds are i'm doing something different.
ie. Oh, you're parsing a string get a numeric value and then setting it with a fallback value/exception. Okay good to know. If it screws up at least I know there is a special behavior here.
Lombok makes these patterns much easier to read though I prefer to only use it for repeat code. Saving one line so you can have @Cleanup doesn't seem worth it to me. It hides too much as you said above, but it varies on the use case.
I still can't figure it out. Why do people still use auto-generated Getters and Setters instead of just making the field public? What is the advantage of using Beans these days? I've never run into a situation where I wanted my getter/setter to do something other than return/set the value.
If you use @Data you say that all fields will be available with getters and setters that will have no other special logic.
Why not consider making those fields public then and not bother with @Data?.
This is how Java language was designed, then everybody started mindlessly putting getters and setters around private fields to pretend they are private while giving everybody access to do whatever they want with them (silly).
Now you are putting @Data to further muddle the problem which basically does not exist.
Records are strange feature. They are immutable, they can't be abstract, they can't extend, they have implementations of some methods. I don't need anything of that. I just need short syntax to declare property with trivial getter/setter and that's about it. This is strange proposal.
The concept of records already exists in other languages, including JVM languages (like Scala and Kotlin). The fact that they're immutable and final is important. If they weren't, there would be subtle bugs caused by that. Scala actively recommends that case classes not be extended precisely due to this fact. Overriding methods for equality and hash code make it such that these classes can be used as keys in maps or entries in sets.
Records are strange feature. > They are immutable, they can't be abstract, they can't extend, they have implementations of some methods. I don't need anything of that.
Some people find data transfer objects to be very useful, even fundamental to implement a well architects software project.
Absolutely agree that Lombok increases Java readability.
If I cannot use JVM alternatives like Kotlin or Scala (for whatever reasons), Lombok is a perfect tool to help beeing productive.
IMO saving one line with @Cleanup is not worth it but if the class doesn't implement AutoClosable, I think it makes code more readable too.
If you absolutely, really need @Data, why not consider making your fields public? I mean, if the only access semantic is going to be exactly the same as public field why have getters and setters in the first place? It just seems dumb to me and not how Java language was designed in the first place. For me it is trying to fix problems of one bad pattern with another bad pattern (now you have two problems).
Readability depends on how large work you do and how much experience you have. Readability is not just how much code you have, it is about using consistent patterns to solve your problems. Readability is how fast and how safely you can move around the code to understand how it works at any level of complexity.
I have 17 years of experience working with Java commercially.
I am blind to getters, setters, builders, and bunch of other stuff. It does not bother me, I can recognize patterns immediately and just ignore them.
What bothers me is when I don't trust my IDE to find all uses of something because some jackass decided to add Lombok to the project and now my IDE does see all code exactly as it will be running.
This is much more of a readability fail.
When you make global refactorings on an application that has over a million lines of code it is absolutely crucial you can trust your IDE to find all uses of something.
This is true as the point of getters and setters is encapsulation, if you totally ignore it there is no real reason to have them at all and public access is a language feature to use.
I somewhat agree with you and reluctant to use Lombok. But it's easy to say "use better language". Kotlin is too different. Java is actually pretty good right now and the only thing I really need is property declaration.
Actually I was thinking about different approach last year, didn't get to implement it. Something like declare abstract class with getX() setX() methods and let library to implement missing methods. Now it's one line per method, no trivial code and able to generate other nice things, e.g. I really want to have fast initializeable properties (like getX throws exceptions until I call setX).
> (like getX throws exceptions until I call setX).
Oh, the wonders of using widespread mutable state! Did you remember to call this other method here before trying to call me??? No?!?! Oh, here's a nasty Exception for you then.
It has nothing with mutable state, actually. I can use this approach with immutable state as well. It's just another value "uninitialized" for property. Like `null` but throws faster (and potentially separate from null, because null could be a valid value).
I'm using it for SQL queries. My query returns subset of some column set. It's not practical to define a separate class for every query. So all queries for the given table returns the same class representing all columns in a given table. But if one method returns subset of those columns, other columns contain uninitialized value and should not be read. Any attempt to use uninitialized value is a bug and must be caught as soon as possible.
"It's not practical to define a separate class for every query."
I'm not sure it's really impractical, at least in my experience. You may not need a separate type for every query, as long as you are willing to have some queries select a few more columns than you actually need right now; and you don't need separate classes, just separate interfaces, which makes the amount of extra code you need smaller.
It's not as simple as use a better language. Often, various organizational constraints Are preventing this. I tried building a new micro-service in Kotlin, right after spring released official support, and there was an incredible reluctance for some team members to learn it. The service was still spring boot with most of the standard patterns but just different enough to make some uncomfortable. Inertia at big companies makes change hard
Edit: The kotlin service was one internal service that I experimented with. Our other 17 production services were standard java spring.
What do you mean by 'not present in the source code'? Annotation processors generate code before the whole codebase is compiled, any tool can analyse the generated lombok source code, the same as with any other code-generating annotation processor.
You do have a point, but if a tool is able to parse Java them I believe it is trivial to extend it to support Lombok, which by now is a quasi standard and fundamental component of a lot of java projects.
Edit: why anyone in their right mind would downvote this comment?
Probably because there is enough people that also value being able to always trace the code written by less experienced team members?
Hint: it is in bad manner to discuss voting on HN. Voting is a popularity contest. If you want your comments to be popular try to be pleasing to everybody and if you don't, don't get upset by downvotes.
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.