Krakow, Poland, 22 - 24 June 2022
Software engineer for over a decade with experience in a wide variety of systems (from mobile to aviation). Member of Resilience4J development team. Java Virtual Machine languages enthusiast, and the Application Programming Interfaces explorer and traveller. A friend of penguins and androids. Allergic to JavaBeans, but addicted to good coffee beans and clean code. Currently develops aviation system for drones.
Are immortal libraries ready for immutable classes?Tools-in-Action
Just a concurrent programming or a job interview topic in the past, day to day class design practice now. For many teams “immutable first” becomes the norm not only for Value Objects or functional paradigm. It’s a natural consequence of constructors’ existence. Software is more and more complex, there is no place for additional effort just for objects’ state tracking. Despite everything, you can hear objections or whispers of temptation:
“It can’t be immutable because of the framework”,
“Don’t do it here, it is just an entity/service/DTO”,
“We don't need another annotation, 5 on each field is enough”.
I'll dispel these myths and show how to make popular Java libraries great tools again (persistence, serialization, mocks and other). They won’t tell you more how to code. Instead of writing God Classes, be a god of your code and write immutable classes whenever you want.