Defects of Immutable collections of Guava?

Question

I am not sure the defects of Immutable collections I understand is correct, so I list them in this answer. Hope someone corrects me here.

a): Comparing to Collections.unmodifiableXXX(), ImmutableXXX.copyOf() loses the source collection feature. For example, when a linkedList is put into ImmutableList.copyOf(), the ImmutableList is not linked anymore. Same as Tree based collection.

b): People think Collections.unmodifiableXXX just uses same reference of source collection, so once the source collection is changed, Collections.unmodifiableXXX is also changed. But my solution is to wrap a source collection into a temp collection which is passed to ImmutableXXX.copyOf(). See code below:

List<String> l = new ArrayList<String>();
List<String>  unmodifiableList = Collections.unmodifiableList(l);
ImmutableList<String> immutableList= ImmutableList.copyOf(l);
l.add("a");//unmodifiableList is also added "a", immutableList not.

/*My solution as follows:
So unmodifiableList2 is also immutable as ImmutableList.copyOf(l) does*/
List<String> unmodifiableList2= Collections.unmodifiableList(new ArrayList(l));

What's your understanding of Immutable collection? Thanks!

Answer 1

Nothing you have mentioned is a "defect".

a) It doesn't matter at all that an ImmutableList is no longer a linked list. The only advantages of a linked list over an array-based list involve adding and removing elements (removing primarily). You can't add to or remove from an immutable list, so array-based is preferable for its fast random access as well as memory efficiency.

For something like TreeSet, there are a number points to consider.

1. A normal ImmutableSet preserves the iteration order of the elements it's given. So if you have a TreeSet and use ImmutableSet.copyOf to create an immutable copy, the copied elements will be ordered the same as in the original.
2. ImmutableSortedSet is the immutable equivalent of TreeSet and uses the natural ordering of elements or a Comparator just like TreeSet does.

b) The fact that you can create a List that happens to be immutable without using Guava doesn't change anything. Guava's immutable collections are designed specifically with immutability in mind and they have various advantages because of that, including (but not limited to):

• The fact that their immutability is guaranteed at the type level, as I mentioned in my answer to your last question. When your method returns something of type ImmutableSet, the caller knows that set can't change on them. Not so if it just returns Set.
• Memory optimizations, including singletons for empty cases and special classes for 1-element cases.
• ImmutableSet.copyOf etc. don't actually copy anything if the input is already an an immutable instance of the same type.
• Methods/builders to make it easy to create immutable collections.

Answer 2

why we need immutable collections

• It dramatically simplifies concurrent programming. Think about it, why is writing proper multithreaded programming hard? Because it is hard to synchronize threads access to a given resource (in this case, the list).

Answer 3

ColinD and Amir answered your specific questions directly, but you might also want to look at GTUG - Using the Google Collections Library for Java (1 of 2) - a presentation about immutable collections by Kevin Bourrillion (Guava's lead developer), where he explains all the advantages of immutable collections.

While the presentation is two years old, and focuses on "Google Collections" (which is now a subpart of Guava), this is a very interesting presentation. The API may have changed a little since the presentation, because the Google Collections API was in Beta at the time, but most of the concepts stayed the same.