0

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?

Rui
  • 1,699
  • Not really a duplicate question, but my answer here may work as answer to your question. – Doc Brown Mar 15 '24 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 Mar 15 '24 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 Mar 15 '24 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 Mar 15 '24 at 18:47
  • This article discusses immutabilty with Jackson: https://www.cowtowncoder.com/blog/archives/2010/08/entry_409.html I think the first thing you should do is make sure you understand what problem they are having. – JimmyJames Mar 15 '24 at 19:13
  • @Rui: if had taken the time to read my answer more thoroughly, you would have understood that it is in no way special to Javascript. To be honest, when I wrote that answer, I was mostly influenced from my C# experience. – Doc Brown Mar 15 '24 at 21:12
  • @DocBrown so according to your answer, immutable object is always encouraged and recommended, isn't it? :) – Rui Mar 16 '24 at 08:49
  • @Rui: didn't I tell you to read my answer thoroughly? Come on, you can do better, read it again. It may help you to counter performance arguments against immutability (still it will probably not help you with arguments based on serialization issues). – Doc Brown Mar 16 '24 at 08:52
  • @DocBrown I read again just now. But the case I used is only a method parameter class including tens of fields. So it would not affect the performance at all – Rui Mar 16 '24 at 10:00
  • 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. – Jörg W Mittag Mar 19 '24 at 18:55

1 Answers1

2

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.

Doc Brown
  • 206,877