Advances in the java programming language, version 16 and newer, slashed a million lines of code from my codebase. Maintaining my programs became easier overnight, due to this 1 secret trick: Records. Unfortunately version 16 was not LTS, so I had to wait until this year’s release of version 21, which is LTS. Go read the linked article. It explains Java Records in a very approachable manner.
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.