Return to Answer

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

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.

In theory, minimizing mutability makes indeed sense, for the well known-reason of reducing the risk of unwanted side effects. That does not mean it is a silver bullet. 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.

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

In theory, minimizing mutability makes indeed sense, for the well known-reason of reducing the risk of unwanted side effects. That does not mean it is a silver bullet. 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 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.

In theory, minimizing mutability makes indeed sense, for the well known-reason of reducing the risk of unwanted side effects. That does not mean it is a silver bullet. 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.