JOracle

Whilst using ADF Faces I have often needed to store a collection of processed data in a backing bean and, rather than accessing a table binding, accessing the collection directly from an af:table or af:iterator component on a page (or in the case of Trinidad tr:table and tr:iterator). Both of these components require that the object backing them be one of these:

• oracle.adf.view.faces.model.CollectionModel
  
• java.util.List
  
• an array
  
• javax.faces.model.DataModel
  

Generally I use a class that implements java.util.List, such as java.util.ArrayList or java.util.Vector. These are fine for unordered data, but when you want the data to be sorted alphabetically, for example, then there are two options that I would always use:

• Sort the list every time a new item is added, or after a group of items is added.
  
• Use a java.util.TreeSet to automatically keep the collection in order when a new item is added, and then copy the values to a list using the iterator each time it is needed.
  

In my opinion both of these options are unsatisfactory - they are either unnecessarily complex and/or have too much overhead. What I would really like is a collection that still acts as a list (implementing the java.util.List interface), but its items are always in order. Unfortunately, Java doesn't supply anything like this in its implementation, so I decided to create one.

At first, I thought I would make a single class that was based on a java.util.TreeMap, but implementing the java.util.List interface. I called it a TreeList and it extended java.util.AbstractCollection and implemented both java.util.Set and java.util.List. I got it working for the cases that I needed it for, but I felt that it was a little lacking in the implementation. For one thing, it didn't implement all the "normal" stuff like Cloneable and Serializable, but the main problem that I saw with it was that it just didn't "fit" in the Java Collections Framework. If it was going to be a generic class for many different situations, it would need to be flexible, extensible and familiar (i.e. work in the same way as other collection classes).

So, I decided to re-write the class with these things in mind. Instead of treating it like a set that acted as a list, I chose to treat it as a list from the start. This class would be based on the pattern of java.util.TreeSet - the class is basically a facade with a java.util.TreeMap backing doing all the work. In the same way, my joracle.util.TreeList would have a backing class that was similar to TreeMap but with the items indexed, hence the class joracle.util.IndexedTreeMap.

As well as these two concrete classes (able to be used out of the box), I also created two interfaces, IndexedMap and SortedList, so that other people can create their own implementations of an indexed map and a sorted list, respectively. There is also an abstract class, AbstractIndexedMap, for the IndexedTreeMap so that work common to all indexed maps can be carried out for the implementer.

Attached to this post is a jar file with both the compiled classes and the source files for these collections.

joracle-collections.jar