Custom Collections

Before we close this chapter we need to look at one additional topic: Why develop custom collections in the first place? Up to this point, we've seen two custom collections. DOMArray.java is an exceptionally simple collection that helps us understand better how collections work. DOMList.java goes a step further and gives a much better understanding about the inner workings of a collection.

There are a number of reasons to develop custom collections, the most important of which follow:

• Application Specific— Perhaps the most obvious reason for a custom collection might be application-specific collections. The previous DOM-based collections are excellent examples of application-specific collections. Certainly other application domains might warrant specific collections.

• Concurrency— One of the drawbacks of the collection classes is that they are not designed to be used concurrently. In fact, they are designed not to be used concurrently with specific wrapper collections designed to support concurrent access, but at a high price: reduced performance. Each time a collection is accessed, via a concurrent wrapper, the entire collection is locked. A very high price to pay. Financial or trading applications could very well need special-purpose high-performance collections that are highly concurrent. Concurrent collections that lock specific records or in other ways better manage concurrent access can easily be imagined.

• Persistence— None of the collections defined in the JDK are persistent. In fact, it might make excellent sense for a DOM-based collection to persist to secondary store. Collections that manage relational or object-oriented databases, Enterprise JavaBeans (EJBs), or other persistent objects might be candidates for persistent collections.

• Special Purpose— Each of the standard JDK collections is by definition general purpose and therefore designed to be useful to the broadest range of developers. But suppose you only need a subset of the functionality? Collections could be developed that offer significantly better insert or get performance but trade off other collection aspects. What about one-way access collections? More and more devices are being developed almost daily. It's not hard to envision a collection that represents all the lights or outlets in a home and provides runtime information on their current use and state.

• Adapter— DOM-based collections are examples of adapter-based collections. Those collections allow you to access some legacy data structure as if it were a collection class. Although Java has only been in existence for a short time, code that we might consider legacy already exists and might be candidates for adapter collections allowing access to legacy data structures but via the newer collection-based interfaces.

• Other Reasons— Convenience, enhanced functionality, the list goes on and on. The JDK collections are general purpose and as a result will not fit every desire.

So how do we choose? Use a existing general-purpose collection or develop a new custom collection? The answer is up to you. If existing collections don't fit your needs, develop a new one, or override an existing collection to add functionality or improve performance in some application-specific domain. But before you do, read the collections documentation, understand all the different collection types and how you might use one, and then proceed from there!