Sorting and CopyOnWriteArrayList

Question

Hi,
Last week I found myself working around the following problem: I have a list of data that is being searched already while new data is still added. Knowing to take care of the dreaded ConcurrentModificationException, I chose the [url http://download.oracle.com/javase/6/docs/api/java/util/concurrent/CopyOnWriteArrayList.html]CopyOnWriteArrayList implementation and I discovered that that class does not play well with Collections.sort():
import java.util.Collections;
import java.util.List;
import java.util.concurrent.CopyOnWriteArrayList;
public class OTNConcurrentArrayListSorting {
     public static void main(String[] args) {
          List<String> l = new CopyOnWriteArrayList<String>();
          l.add("oracle");
          l.add("java");
          Collections.sort(l);
}leads to:
Exception in thread "main" java.lang.UnsupportedOperationException
     at java.util.concurrent.CopyOnWriteArrayList$COWIterator.set(CopyOnWriteArrayList.java:1013)
     at java.util.Collections.sort(Collections.java:121)
     at OTNConcurrentArrayListSorting.main(OTNConcurrentArrayListSorting.java:12)This came as a surprise to me, but it is documented and after a bit of thinking quite understandable. After all what good is sorting if new elements are added to the list unseen and not taken into account in the sort.
The way I worked around it, is using a binary search to find out where to add the new element and thus keeping the list sorted at all times. Only in preparation of this post, it occurred to me that I'd need the additions to be synchronized for that idea to work, so I ended up with this fragment:
synchronized (revolutions) {
     int i = Collections.binarySearch(revolutions, info);
     if (i < 0) {
          revolutions.add(-(i+1), info);
}I am not unhappy with the solution and it serves the purpose, but still I wonder whether there's a better alternative. Any ideas?

Answer 1

Great suggestion! The list I am maintaining is a sort of index for elements like this, where the number is positive and the interval is a start and end date (the intervals are non overlapping and their sorting goes hand-in-hand with the number):
      * Packs the revolution number and the date range covered by it,
      * while {@link #compareTo(RevolutionInfo)} orders according to the number.
     private static class RevolutionInfo implements Comparable<RevolutionInfo>{
          int number;
          Interval span;
          @Override
          public String toString() {
               return "Revolution "+number+" "+ span.toString();               
          @Override
          public int compareTo(RevolutionInfo o) {
               return number - o.number;
     }I need to support both a search by number to retrieve the Interval of dates (an exact match, will work very well with the HashMap) and a search by date to get the revolution number. The two are now unified in one piece of search code and two different Comparator implementations.
I am already maintaining an underlying datastructure in a HashMap, which I could use to improve the by number lookup-performance. By the way, the main (and measured) performance penalty I am trying to avoid is the following. I have a datastructure SkyMap, one per revolution (we'll reach 1000 in a couple of weeks) which I read from a 2 Mb XML-file (which is 400 maps, benchmarked at ~8 maps per second). In one use case, all the maps are alredy pre-loaded and can be served out of memory. In a much rarer use case, the maps are being loaded and a request (get number for a given date) needs to be handled: it's here that I want to remove the overhead of waiting for the entire file to be processed, but go about the business as soon as the SkyMap covering that date is available.