[safaci2000]

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.

[foxyv]

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.

[lunias]

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() { ... }

[azth]

> 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.

[mkurz]

> 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")

[lmilcin]

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.

[pacala]

hash, equals, toString.

[vbezhenar]

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.

[azth]

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.

[rumanator]

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.

[rienbdj]

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.

[_ZeD_]

never soon enough!

[tuczi]

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.

[lmilcin]

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.

[democracy]

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.