Read-only collections are directly supported by the .NET platform (ReadOnlyCollectionBase). Unfortunately Java support for unmodifiable collections is limited with many pitfalls along the way.

This "tips & tricks" is more or less a summary of a current Javalobby discussion ( Mustang versus Tiger performance comparison ). Hopefully it will help Javalobby readers to avoid common pitfalls with read-only collections.

1. The Collections utility class.

Providing a read-only view of any collection/map/set/list in Java seems straightforward using the java.util.Collections utility class. For example:

    List<String> readOnlyList = Collections.unmodifiableList(myList);

The first thing you notice is that read-only collections are not differentiable from normal collections. In fact, there is nothing to indicate that a collection is read-only (there is no ReadOnlyList interface with read-only methods for example). The user has still access to the add/set/remove methods but calling these methods results in UnsupportedException being raised.

2. Read-Only view of mutable collections.

Let's say that you have a collection of existing "Units", and you want to provide users with a read-only view of these units. Unfortunately, the following code will fail miserably:

public class Unit {
     static ArrayList<Unit> INSTANCES = new ArrayList<unit>();
     public static List<Unit> getInstances() {
         return Collections.unmodifiableList(INSTANCES);
     }
}

Why? Because, it the user iterates on the read-only list of units while a new unit is added to the collection (by another thread) a ConcurrentModificationException is automatically raised.
A major issue with ConcurrentModificationException is that there is no certainty you will discover the problem during testing. You can imagine two threads one updating a collection and the other one iterating the collection. As long as the update is not performed while the other thread is iterating, everything is fine (no ConcurrentModificationException)! But, if for a reason or another the timing changes (e.g. in the user environment) and iterations are performed at the wrong time you will crash... Not a good thing and very high probability for this to happen

3. Copy on Write Solution.

The java.util.concurrent package provides two classes CopyOnWriteArrayList and CopyOnWriteArraySet which basically copy the underlaying collection each time a modification occurs (keeping the read-only view immutable). This approach can be generalized to any collection or map. For example:

class Dictionary {
    private HashMap<String, String> _definitions;
    public Map<String, String> getDefinitions() { // Read-only view.
        return Collections.unmodifiableMap(_definitions);
    }  
    void define(String word, String definition) {
        HashMap<String, String> definitions = new HashMap<String, String>(_definitions); // Copies collection.
        definitions.put(word, definition);
        _definitions = definitions;
    }
    ...
}

Still, this approach is very expensive especially for large collections as it requires a whole copy of the collection for each update.

4. Allowing safe concurrent modifications.

Another solution to this problem is to allow thread-safe modifications of the collection. For example, the Javolution (http://javolution.org) collections allow for concurrent modification as long as the collection elements (or map entries) are not removed. In other words, there is no need to "Copy on Write" unless deletion occur. A far less occurence. Often collection elements are never removed or if they are it is because the whole collection is cleared (in which case there is no need for copying the existing collection, just replacing with a new empty collection is just fine). Here is the units collection example using Javolution FastTable:

public class Unit {
     static FastTable<Unit> INSTANCES = new FastTable<unit>();
     public static List<Unit> getInstances() {
         return INSTANCES.unmodifiable();
     }
}

Here is the dictionary example:

public class Dictionary {
    private FastMap<String, String> _definitions = new FastMap<String, String>();
    public Map<String, String> getDefinitions() { // Read-only view.
        return _definitions.unmodifiable();
   }  
   void define(String word, String definition) {
       _definitions.put(word, definition);
   }
   void removeWord(String word) {
       FastMap<String, String> definitions = new FastMap<String, String>(_definitions); // Copies collection.
       definitions.remove(word);
       _definitions = definitions;
   }
   void clear() {
       _definitions = new FastMap<String, String>();
   }
}

For more information on Javolution collection see: javolution.util pkg

 public class InvalidationList<T> implements List<T> {
  private final List<T> originalList;
  private int modCount;
 
  public InvalidationList(List<T> originalList) {
    this.originalList = originalList;
  }
 
  public boolean add(T o) {
    synchronized (this) {
      boolean b = originalList.add(o);
      modCount++;
      return b;
    }
  }
 
  public int size() {
    return originalList.size();
  }
 
  // more delegates like add... and size
 
  public List<T> unmodifiable(){
    return new InnerList(this);
  }
 
  static final class InnerList<T> implements List<T> {
    private List<T> delegate;
    private final InvalidationList<T> parentList;
    private int modCount;
 
    public InnerList(InvalidationList<T> parent) {
      parentList = parent;
      invalidate();
    }
 
    public int size() {
      checkInvalidation();
      return delegate.size();
    }
 
    private void checkInvalidation() {
      if (parentList.modCount > this.modCount) {
        invalidate();
      }
    }
 
    private void invalidate() {
      synchronized (parentList) {
        this.modCount = parentList.modCount;
        delegate = Collections.unmodifiableList(new ArrayList(parentList.originalList));
      }
    }
 
    
    // more delegates.... like size();
    
  }
}