Programmer and mathematician. Problem solver. Lover of clean code, coffee, cycling, running and Italian food.
Kotlin, Java, Spock (Groovy), PHP, Angular, MariaDB, ...
I agree, it is unfortunately not possible to upgrade yet for everyone. But most Android development uses Kotlin (and data classes). For legacy applications it is also not always viable to add a dependency like Lombok to the code base.
As for the shallow immutablility, your own example (OldClass) is also mutable. Date and List can both change their content (for example setTime and add) without changing their reference.
I'm actually recommending to use the immutables library instead of lombok, that library generates code and does NOT include any runtime dependency to the classpath/modulepath.
You are right about the Date and List data types in the example, those are actually intentional to demonstrate that we have to take care of those things when we want to write immutable objects by hand. The immutable library takes care of the Collections situation creating copies, unfortunately the only way of fix the Date issue is using another alternative like java.time.LocalDate
if you have the time please take a look to this post as well and any feedback would be helpful:
Hello Carlos.
I agree, it is unfortunately not possible to upgrade yet for everyone. But most Android development uses Kotlin (and data classes). For legacy applications it is also not always viable to add a dependency like Lombok to the code base.
As for the shallow immutablility, your own example (OldClass) is also mutable. Date and List can both change their content (for example setTime and add) without changing their reference.
I'm actually recommending to use the immutables library instead of lombok, that library generates code and does NOT include any runtime dependency to the classpath/modulepath.
You are right about the
Date
andList
data types in the example, those are actually intentional to demonstrate that we have to take care of those things when we want to write immutable objects by hand. The immutable library takes care of theCollections
situation creating copies, unfortunately the only way of fix theDate
issue is using another alternative likejava.time.LocalDate
if you have the time please take a look to this post as well and any feedback would be helpful:
☕️ Immutables/AutoValue/Lombok 🔥 Which One?
Carlos Chacin ☕👽 ・ Apr 13 ・ 5 min read