Java Collections & JGL

Java Collections

The Collections Framework

A framework is a set of classes that form the basis for building advanced functionality. A
framework contains superclasses with useful functionality, policies, and mechanisms. The user
of a framework forms subclasses to extend the functionality without having to reinvent the basic
mechanisms. For example, Swing is a framework for user interfaces.
The Java collections library forms a framework for collection classes. It defines a number of
interfaces and abstract classes for implementors of collections (see Figure 2-10), and it prescribes
certain mechanisms, such as the iteration protocol. You can use the collection classes without
having to know much about the framework—we did just that in the preceding sections. However,
if you want to implement generic algorithms that work for multiple collection types or if you
want to add a new collection type, it is helpful to understand the framework.

1
Java Collections & JGL

The actual classes:

2
Java Collections & JGL

The Jakarta Commons Collections component

Many specialized implementations are well defined and understood, but they are
not part of the core Collections Framework yet. Several of these implementations
might be included with the concurrency utilities library (JSR 166) discussed in more
detail later.

The Jakarta Commons Collections component is one example of a set of specialized

implementations. Designed to work with J2SE 1.2, the Commons Collections
component provides two List implementations and eight Map implementations.
New base structures are also available and are the most interesting.

Let's look at the custom implementations in groups.

The simplest to explain are the FastArrayList, FastHashMap, and FastTreeMap

implementations. These extend the standard ArrayList, HashMap, and TreeMap
implementations that offer safe simultaneous read-write access from multiple
threads. However, safety comes at the cost of slower write operations. While the
read operations aren't synchronized, the write operations are performed on a data
clone before the existing structure is replaced.

The Bag acts like a Set but permits duplicates. Two more implementations are
available here: HashBag and TreeBag; the latter is sorted.

Another new interface is PriorityQueue. It supports comparable items and the use
of a Comparator, so items can be maintained in a BinaryHeap based on priority and
subsequently removed from the heap based on that priority.

The remaining implementations are a set of specialized Map implementations. They

offer special-purpose, key-value pair lookup maps.

 BeanMap uses reflection to provide key-value pairs based on JavaBean

properties; the key is the property name, and the value is its value.

 ExtendedProperties provides an extension to the java.util.Properties

class that concatenates multiple values for a single property, instead of
overwriting it.

 LRUMap is a Map that lets you maintain a maximum capacity and uses a least-
used (accessed) algorithm to determine which node to remove when full.
This capability is already accessible from the standard LinkedHashMap class,
but is only available with J2SE 1.4
.
 SoftRefHashMap works like WeakHashMap but uses SoftReference instead of
WeakReference for its keys.

 MultiHashMap provides a multimap, where keys can have multiple associated

values. Fetching the value for a key returns a Collection instead of the
specific value for the key.

3
Java Collections & JGL

 DoubleOrderedMap is the most interesting of the bunch. It provides a Map

that supports fast lookup by value and by key. It has one requirement
though: both keys and values must be unique. You can do this with two
TreeMap objects, but DoubleOrderedMap only saves each key-value pair
once.

Other classes and interfaces serve mostly supporting roles, but some specialized
behavior is available. Besides utility methods to work with sets like
isSubCollection and union, the framework includes additional Comparators and
Iterators. The Comparators are used mostly for chaining or changing another
Comparator's behavior. For instance, while
java.util.Collections.reverseOrder() lets you reverse the natural order of
elements, the ReverseComparator class lets you reverse the order from any
Comparator. The Iterators support the process of passing each Collection
element to a function (method) before getting the element back. This is a shared
behavior of JGL and STL too.
[http://www.javaworld.com/javaworld/jw-11-2002/jw-1101-collections-p2.html ]

4
Java Collections & JGL

JGL – Java Generic Library

Philosophical differences
The immediate, high-level difference between Collections and JGL appears to be
one of philosophies. Sun and ObjectSpace have different outlooks, and offer us
solutions that reflect their distinct perspectives.

JGL is a direct descendant of STL, C++'s Standard Template Library. (The major
STL/JGL difference: STL is hard to exploit properly, while exploiting JGL is a breeze.
This difference has little to do with the libraries themselves, but instead reflects the
difference in ease of use of the two targeted languages: C++ and Java.) JGL
inherits STL's fundamental library architecture, as depicted by Figure 1 below.

With Collections, the name of the framework itself is tell-tale: Collections focuses
mainly on containers, rather than on containers and algorithms. This is a very
different approach from JGL, which treats algorithms and containers as equals. This
fundamental difference leads to more differences down the line, eventually
diverging into large areas where the two frameworks have little in common.

5
Java Collections & JGL

The iterator interface hierarchies for JGL and Collections.

[ http://www.javaworld.com/javaworld/jw-01-1999/jw-01-jglvscoll-p2.html ]

JGL: An overview
The problem domain JGL focuses on can be expressed in Niklaus Wirth's immortal
formula: algorithms + data structures. Or rather, in this object-oriented era: data
structures + algorithms.

On the data structures side, JGL makes available a set of Abstract Data Types
(ADTs) that are derived from an abstract class called Container -- actually defined
as a Java interface. Containers are further sub-categorized into the following (as
shown also in Figure 1):

 Sequences -- comprising arrays, single/double linked lists, and Dequeues

(double-ended queues)

 Sets -- hashing and ordered

 Maps -- hashing and ordered

 Queue

 Stack

All sequences (containers in which element ordering plays a role) and sets
(containers in which element ordering is unimportant) "descend" from their
respective interfaces -- that is, Sequence and Set -- which inherit from interface
Container. (Do not confuse the AWT Container class with JGL's Container: The
two classes are unrelated.)

6
Java Collections & JGL

On the algorithms side, object-oriented inheritance is much less useful, so JGL's

algorithms are simply grouped loosely into unrelated classes with names generally
ending in -ing. Here are some of the main algorithm classes:

 Sorting

 Finding

 Filtering

 Counting

 Replacing

 Reversing

 Applying

 Transforming

 Copying

Both groups of classes, data structures, and algorithms, can be coupled together
with the help of a host of helper classes: iterator and function classes.

Iterator classes will be familiar to most experienced object-oriented programmers:

They are abstract pointers to elements of abstract data structures. The JGL
provides iterator classes not only for each of its Container classes but also for
every native Java array variety and for java.util's Vector class. JGL lets you use
native Java arrays and class Vector as first-class JGL citizens, via mediating classes
called array adapters.

Function classes let you encapsulate "functions" (method calls, condition functions)
as objects that you can then apply "in bulk" to containers in myriad different ways.
For example, if you had a "convert to uppercase" function, you could convert every
string in any container to uppercase, irrespective of whether the container is a
linked list, a native Java array, a hashtable, or a set, and so on.