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.

Mostly just convention, but it's also a more flexible pattern. A public instance variable cannot have public reads, but private writes for instance.

There is also the case of derived properties. e.g.

LocalDateTime ranAt

LocalDateTime finishedAt

getRuntime() { ... }

> but at least the @Data annotation makes it much more readable IMO.

Record types for Java are being worked on, and we should be getting them hopefully at some point in the (near) future.

> Record types for Java are being worked on, and we should be getting them hopefully at some point in the (near) future.

Just 2 days ago JEP 359 [0] was marked to be fixed [1] in Java 14 (as preview feature)!

[0] https://openjdk.java.net/jeps/359

[1] https://bugs.openjdk.java.net/browse/JDK-8222777 (see "History")

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.

hash, equals, toString.

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.

If you want an object with a few getters and setters, just make a class.

This proposal is to remove the boiler plate of creating immutable objects with value semantics.

never soon enough!

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.

For non-toy projects, those strengths greatly outweigh the language's flaws.

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.

How does Lombok decrease reliability of tools?

Lombok creates new code that is not present in the source code. This throws off tools in some cases.

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.

> Probably because there is enough people that also value being able to always trace the code written by less experienced team members?

You can trace/debug lombok generated code though...

It’s not that hard to just run delombok and then run these tools.