The Jakarta Commons Collections Package

Developers Guide

$Id: DEVELOPERS-GUIDE.html,v 1.2 2002/07/03 02:34:09 mas Exp $
[Introduction] [Collection Interfaces] [Collection Implementations] [Utility Classes]

1. INTRODUCTION

The Collections package contains a set of Java classes that extend or augment the Java Collections Framework. This developers guide seeks to set out rules for the naming of classes and methods within the package. The purpose of this, as with all naming standards, is to improve the coherency and consistency of the whole API.

The philosophy of the naming standards is to follow those of java.util.Collections.

2. COLLECTION INTERFACES

Collection interfaces are new types of collections not included in Java. Examples include Bag and SortedBag. These interfaces shall:

3. COLLECTION IMPLEMENTATIONS

Collection implementation are new implementations of collection interfaces. Examples include DoubleOrderedMap and DefaultMapBag. These interfaces shall:

4. UTILITY CLASSES

Utility classes provide additional functionality around an interface and its basic implementations. Examples include CollectionUtils and ListUtils.

Each class shall follow the naming pattern XxxUtils where Xxx relates to the object being returned by the class, for example ListUtils and BagUtils. Variations on a theme (SortedBag as opposed to Bag) will be dealt with in one Utils class. Each Utils class shall:

Where the method in a Utils class is a decorator, the name shall consist of an adjective followed by the collection type. Typically such adjective is formed by appending an -ed suffix (meaning "having"/"characterized by") to the word describing the type of decorator. For example, synchronizedMap(Map) or predicatedSet(Set). Occasionally, such construct is awkward and a more suitable adjective can be used instead. For example, lazyList, unmodifiableList.

Typically, these decorators should be implemented as non-public, static, inner classes; however, if warranted due to maintenance or other reasons, these decorator classes may be moved to top-level classes in a subpackage. The naming of such a subpackage should be discussed and agreed upon on the developers mailing list.