Thread safety

The original Java collections classes used synchronized methods to provide thread safety. Unfortunately, this had the side effect of lowering performance due to the synchronization overhead. For the common case where the collection is only being used by one thread the synchronization overhead is a pure waste of cycles.

To avoid this problem, the collection classes added in Java 2 use unsynchronized methods. For cases where a collection needs to be shared between threads a synchronized wrapper can be used to assure that only one thread can access the collection at a time.

This library uses unsynchronized methods to provide the best performance. However, since each type-specific class defines methods using a different type, it isn't possible to simply define a wrapper class to handle the synchronization. Instead, if you need thread-safe versions of the classes you'll need to modify the classes (or subclass them) to add the "synchronized" keyword on the public access methods.

Class structure

The classes included in this library are designed to share as much code as possible in order to minimize the space overhead of creating variations for different types. At the same time, we've avoided using coding techniques which would reduce the code size at the cost of execution speed. After several refactorings we've arrived at a structure that offers good trade offs between these goals.

This structure uses two underlying layers of abstract classes. The first layer class provides basic support for the general collection category (linear, primitive hash or object hash). The second layer adds specialized support for a particular format within the category (such as array, queue, or stack, for the linear category).

Actual implementation classes extend one of the second layer abstract classes. Each format requires a few type-specific methods to be defined in the implementation class, as discussed in the JavaDoc package documentation. It's important to note that a number of the useful public methods are actually inherited from one of the abstract base classes, though, so these are not obvious in the JavaDocs for the implementation class. Here again, check the JavaDoc package documentation first for an overview of how to use the implementation classes:

Arrays package:com.sosnoski.util.array
Hash maps package:com.sosnoski.util.hashmap
Hash sets package:com.sosnoski.util.hashset
Queues package:com.sosnoski.util.queue
Stacks package:com.sosnoski.util.stack