Downsides to immutable objects in Java? [closed]

Question

The advantages of immutable objects in Java seem clear:

• consistent state
• automatic thread safety
• simplicity

You can favour immutability by using private final fields and constructor injection.

But, what are the downsides to favouring immutable objects in Java?

i.e.

• incompatibility with ORM or web presentation tools?
• Inflexible design?
• Implementation complexities?

Is it possible to design a large-scale system (deep object graph) that predominately uses immutable objects?

Answer 1

But, what are the downsides to favouring immutable objects in Java? incompatibility with ORM or web presentation tools?

Reflection based frameworks are complicated by immutable objects since they requires constructor injection:

• there are no default arguments in Java, which forces us to ALWAYS provide all of the necessary dependencies
• constructor overriding can be messy
• constructor argument names are not usually available through reflection, which forces us to depend on argument order for dependency resolution

Implementation complexities?

Creating immutable objects is still a boring task; the compiler should take care of the implementation details, as in groovy

Is it possible to design a large-scale system (deep object graph) that predominately uses immutable objects?

definitely yes; immutable objects makes great building blocks for other objects (they favor composition) since it's much easier to maintain the invariant of a complex object when you can rely on its immutable components. The only true downside to me is about creating many temporary objects (e.g. String concat was a problem in the past).

Answer 2

With immutability, any time you need to modify data, you need to create a new object. This can be expensive.

Imagine needing to modify one bit in an object that consumes several megabytes of memory: you would need to instantiate a whole new object, allocate memory, etc. If you need to do this many times, mutability becomes very attractive.