23
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 25 Oct 2023
23 points (96.0% liked)
Java
1367 readers
1 users here now
For discussing Java, the JVM, languages that run on the JVM, and other related technologies.
founded 1 year ago
MODERATORS
I feel like so much effort is spent trying to solve problems that just aren't problems.
Creating simple data objects (or what we used to call Java Beans) is ready to do - especially in a modern IDE. It's also simple to understand what is happening in one and different take very long to read at all.
I can count on the fingers of one hand the number of times I've actually needed to write a hash or equals method.
But the solution to this, in my opinion, non problem is to use a highly inflexible tool that only works in a subset of cases - e.g. when it's ok for your data objects to be immutable.
I don't think your belief has any merit.
The popularity of tools such as Lombok and JVM languages such as Kotlin demonstrate the pressing need to eliminate the need for boilerplate code in Java to do basic things.
It matters nothing if an IDE can generate all the getters and setters you wish. The problem is the need to generate all those getters and setters for a very mundane and recurrent usecase. All this boilerplate code adds to the cognitive load and maintenance needs of all projects, and contribute to the introduction of bugs.
That's fine. Other people write code and are able to assess their own needs, and the verdict is that not having to write boilerplate code beats having to write it.
If your personal experience was shared by many, Lombok or Kotlin would not be popular.
I can't count on one hand the number of times I've needed to write hashcode/equals in the last week. It's easy to do and records would make it harder to get wrong.