0

An interviewer asked me about the disadvantages of making classes immutable. I gave an answer regarding the heap space that is occupied by immutable objects and how it brings down the performance of Java applications.

What are other disadvantages of making objects immutable in Java?

Pops
  • 30,199
  • 37
  • 136
  • 151
Tuntun Rgrirb
  • 11
  • 1
  • 1
  • 1
    @dfa answers this quite nicely [here][1]. [1]: http://stackoverflow.com/questions/752280/downsides-to-immutable-objects-in-java – CodeChimp Mar 05 '13 at 17:04

4 Answers4

1

The disadvantage is that you must create a new object to change its "value". If your class is representing something that "changes" frequently, you'll create a lot of objects, putting load on the garbage collector.

Bohemian
  • 412,405
  • 93
  • 575
  • 722
  • 1
    I think that the problem of memory consumption (and by extension garbage collection) is probably the most important consideration, though Java strings shows the opposite reasoning, there are a lot of them, and they can change very frequently, but since they can share internal address space, making them immutable actually improves memory usage. +1 – RudolphEst Mar 05 '13 at 17:27
  • 1
    @RudolphEst only constant (ie hard coded) strings are interned. If a string "changes", a new string is created – Bohemian Mar 05 '13 at 18:38
0

You should also consider that it may be much more difficult to deserialize/materialize immutable objects, since it usually involves writing a class with no parameter-less constructor.

haim770
  • 48,394
  • 7
  • 105
  • 133
  • This is a valid point, but in general, even classes with only parameterised constructors can be serialized and deserialized using the [ConstructorProperties annotation](http://docs.oracle.com/javase/6/docs/api/java/beans/ConstructorProperties.html) – RudolphEst Mar 05 '13 at 17:24
  • Indeed. yet it add complications to the use of Hibernate (for example) or some serializers. – haim770 Mar 05 '13 at 17:30
0

Lets take a BigInteger

BigInteger i1 = BigInteger.valueOf(1);

it has add method, but you cannot add 1 to it, it's immutable, so what you do is

BigInteger i2 = i1.add(i1);

that is, a new object is created each time, ie arithmetic with immutable BigInteger is very slow

Evgeniy Dorofeev
  • 133,369
  • 30
  • 199
  • 275
-1

If there is no application requirement that your object be mutable, there is no disadvantage to making it immutable and you should do so.

If there is an application requirement your object is mutable, then make it mutable.

djechlin
  • 59,258
  • 35
  • 162
  • 290
  • What application requirement would specify that an object _has to be_ mutable? Immutable objects are never changed, but that does not mean a new object cannot be created with a single property changed. I think mutability versus immutability of Java objects is less a question of application requirements and more a question of style. We are all used to immutable Java strings... – RudolphEst Mar 05 '13 at 17:04
  • @RudolphEst e.g. a chat server that keeps track of who is logged in, a profiler that counts total emails processed, a worker that stops listening for work when it's received it's max # of concurrent tasks or shuts down... – djechlin Mar 05 '13 at 17:06
  • @RudolphEst I suppose there's purely functional workarounds for the first two of those, but I don't know any way a long-running object can simultaneously support shutdown and immutability. – djechlin Mar 05 '13 at 17:08
  • Immutable objects are useful even when functional techniques are not. Agreed, that may be overkill in a Java environment. Mostly though I am thinking of immutable classes for use as data objects, and not in other cases. I agree strongly that monads and other functional _magic_ (at least to us poor Java devs) are required when the immutability gets complicated, but it can be done. – RudolphEst Mar 05 '13 at 17:19