Are Java Record Classes Truly Immutable?
Why does java introduce record classes?
Main purposes of introducing record classes:
- Reducing boilerplate code for data transfer objects. Java developers almost always write boilerplate codes such as accessors, mutators, equals, hashcode, and toString methods for data transfer objects. Using Lombok can help avoid this issue, but it adds an external dependency
- Making immutable object creation easy and handy. To create immutable java classes, classes need to be declared as final, all fields should be private and final too, accessor methods should be used carefully, we should not provide mutator methods, etc.
If you don’t have a medium membership, you can use this link to reach the article without a paywall.
So, Record classes are created mainly because of those reasons. With record classes, java developers will be able to create immutable objects without boilerplate code. However, the question remains: “Are Java Record Classes Really Immutable?”.
Answer is NO!
Yes, it is correct. Record classes are not immutable. Rather, UNMODIFIABLE is the term used to describe its functionality.
Mutable object fields break the immutability of records. If your record contains a possible mutable object as a field, this will break the immutability of the java record class. For example, if your record contains a list field, the canonical constructor will just assign the given list to the field and in the case of a change of list content, the record class field will also be changed. A code example has been provided to demonstrate how it works.
Guest record class:
We expect the same output from both printing operations when an immutable object is used to create this data transfer object, but we get different output with the above code. 👇
Guest[name=Test, age=28, emails=[[email protected], [email protected]]] Guest[name=Test, age=28, emails=[[email protected], [email protected], [email protected]]]
This is happening because of the email field. It uses a mutable object to keep data, hence content of the email field changes when the content of the original list is changed.
There is a way to avoid the mutable field problem. Deep copy. By copying the content of the original parameter to the field, this immutability-breaking problem can be handled. So overriding the canonical constructor is required in that case.
When we copy the content of the parameter to the field by overriding the canonical constructor, changes on the original parameter will not affect our object anymore. The output is changed after copying the content.
Guest[name=Test, age=28, emails=[[email protected], [email protected]]] Guest[name=Test, age=28, emails=[[email protected], [email protected]]]
Copying content saves you from immutability issues. But a few points need to be checked.
- List.copyOf function is not null safe. If the emails parameter is null or one of the items of the emails parameter is null, It will cause a NullPointerException. Copying with another method with null safety can be more useful.
- List.copyOf function provides an unmodifiable list. So when the emails field of the guest object is accessed and assigned to another variable, changing content will not be possible. Hence overring accessor method is not required in this implementation
- If you want to keep it null safe, and at the same time be able to modify record content without affecting the record below approach can be used.
By overriding the accessor method, the content of emails will still be editable when assigned to a variable and the record will not be affected by that change.
Hope you understand the difference between unmodifiable and immutable data types, and how to implement your own immutable record class.
👏 Thank You for Reading!
👨💼 I appreciate your time and hope you found this story insightful. If you enjoyed it, don’t forget to show your appreciation by clapping 👏 for the hard work!
📰 Keep the Knowledge Flowing by Sharing the Article!
✍ Feel free to share your feedback or opinions about the story. Your input helps me improve and create more valuable content for you.
✌ Stay Connected! 🚀 For more engaging articles, make sure to follow me on social media:
🔍 Explore More! 📖 Dive into a treasure trove of knowledge at Codimis. There’s always more to learn, and we’re here to help you on your journey of discovery.
