Is immutable objects over POJO in general?

Question

Lombok is used in the legacy project where I am currently working for since last year. The project is legacy with 10+ years, and POJO/JavaBeans, i.e. @Data annotated classes, have been widely used for probably 10+ years.

However, since I have been using Lombok for many years in other companies, I just prefer to using the immutable@Value objects whenever possible. But some of my team members had serialization problems with Jackson in his local IDE, so they seems not like it, and one of them gives the following comments

I usually prefer @Data over @Value because there’s always a good chance that immutability will cause unexpected problems (such as this).

The detail of such as this problem is only this much from my teammate:

I’m getting complaints about Jackson not being able to deserialize the parameter object (e.g. XXXParamsVO) because of the lack of a proper constructor. And indeed there is no no-args constructor in those classes

I never had any compilation problems in my IDE, so honestly imo this sounds absurd. Not only one book recommend the use of immutable objects, a typical one is in Effect Java, where there is an item

Minimize mutability

and in that section, it was told clearly why immutable objects should be used.

I would like to ask any more experienced developers opinions about this. Does the "minimize mutability" really not make sense?

Answer 1

In theory, minimizing mutability makes indeed sense for several use cases, for the well known-reason of reducing the risk of unwanted side effects. That does not mean it is a silver bullet, or that this design should be always chosen without thinking. But as I wrote in my former answer, a good rule-of-thumb is IMHO to use immutability for data structures with only a few attributes based on primitive or other immutable types.

In reality, however, there can be cases where immutability can cause trouble with certain tools, that's not "absurd", as you wrote, that's simply reality. When you use certain frameworks, they might expect classes with a parameterless constructor. A naive serialization framework might not be able to deserialize objects without constructing an empty object first, then require public setters to fill the attributes.

Still, any production-ready serialization framework should provide means for dealing with this basic issue, and as the article provided by @JimmyJames shows, there are several approaches to make Jackson work with immutable objects. One has to learn and understand them, then make a decision and pick one. This always requires a little of extra boilerplate.

Same holds for other tools like IDE's: immutability is not a cutting-edge idea (I think I first grasped it when I came in touch with SICP, which is from 1984). Any Java and C# programmer has to work with an immutable string class regularly, so it is nothing they should not have seen before. If an IDE today has trouble with immutable data structures and forces you to use mutable data structures, I would consider the IDE as broken and recommend to change or update the IDE.

It might be also possible that your colleague simply does not like immutability, or does not like having to make further considerations when using certain tools and frameworks, or does not like the extra boilerplate. When people don't like something, they will find excuses for avoiding it. If that applies to your case (or not) is something you have to work out with them, not with us.