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?

  • Not really a duplicate question, but my answer here may work as answer to your question.
    – Doc Brown
    Commented Mar 15 at 18:17
  • @DocBrown the question u answered is in the domain of JavaScript, which is more obvious about the prevalent use of immutable objects. I guess that is difficult to persuade my team members
    – Rui
    Commented Mar 15 at 18:20
  • Can elaborate on the problem your team member was facing? I assume that Jackson uses setters to deserialize data but it would be better to explicitly describe the issue in your question.
    – JimmyJames
    Commented Mar 15 at 18:27
  • @JimmyJames I added the problem details there, I don't know the problem stack, either since my local IDE never had that problem. But indeed a couple of my teammates encountered that problem even though that problem never appear in the production environment
    – Rui
    Commented Mar 15 at 18:47
  • 2
    I have a feeling the problem has nothing to do with mutability but with the fact that your IDE settings are not synchronized within your team and you don't have reproducible builds. Commented Mar 19 at 18:55

1 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.

  • btw the IDE we are using is the IntelliJ Community
    – Rui
    Commented Mar 16 at 13:07
  • I agree esp. on the last paragraph u posted
    – Rui
    Commented Mar 16 at 13:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.