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.
You must log in or register to comment.
Groovy did this ages ago- I don’t do much groovy anymore, but the more I use other languages (nodeJS, python, etc) the more I appreciate all the developer friendly language features it has (and has had for over a decade). I find myself having to use lodash and its variants on other platforms to make up for the lack of all the really useful functional methods and lambdas.
I’ll be honest, I still haven’t figured out how to properly replace my POJOs with records. I tried a few weeks ago (17) and it was definitely not a plug n play situation. I don’t remember exactly the friction I ran into but I quickly abandoned it in favor of POJOs to get a POC done. I need to revisit it and see what the issue was. I think it was field accessibility or something like that.
What major Java supporting ide doesn’t support Lombok? Even vs code with Java extensions supports it.
And the third party dependency is a weak argument. You will have dependencies in any major application. Lombok is a well tested dependency at least.
Nothing against records, working on using them more but they don’t always play nice with hibernate.
But I guess that’s another terrible third party dependency we should all avoid.
What major Java supporting ide doesn’t support Lombok?
Why would everyone have to onboard a code generator just to be able to use data transfer objects without having to write tons of boilerplate?
Also, Java records allow the runtime to optimize how these instances are handled.
I already tend to have the code generator for various other abilities it offers. Things like annotations for logging, Val, and builders are just very practical and Java doesn’t otherwise have a way to get rid of that boilerplate.
If I can use a record I will now (especially since we are now on Java 17) but like I said, I haven’t been able to make spring and hibernate play nice with records so far so I’m stuck with classes for some @data things
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 feel like so much effort is spent trying to solve problems that just aren’t problems.
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.
I can count on the fingers of one hand the number of times I’ve actually needed to write a hash or equals method.
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.
