Design Patterns in JDK Collections

Christine BouamalaySBC Services, San Ramon, CA

Design Constraints for a Standard Data Structures Library

● Used directly or indirectly by every programmer for everything within its scope

● Primitive in the mathematical sense: individual components designed to perform only a single role

● Invaluable and affordable to essentially every student and professional programmer

Design Constraints for a Standard Data Structures Library (con.)

● Convenient, efficient, and reasonably safe for common use

● Complete at what they do● Supportive of commonly-accepted

programming stylesBjarne Stroustrup, The C++ Programming Language (Special Third Ed.), Addison-

Wesley, 2000.

Forces between contradictory constraints

● Used directly or indirectly by every programmer for everything within its scope

● Primitive in the mathematical sense: individual components designed to perform only a single role

● Invaluable and affordable to essentially every student and professional programmer

● Convenient, efficient, and reasonably safe for common use

● Complete at what they do

● Supportive of commonly-accepted programming styles

Tradeoffs between Design Goals: How elaborate a Hierarchy?

Initial: Standalone Vector (Stack?!), Hashtable

JDK 1.2 Framework

Interfaces, Abstract Classes

Application-level Classes

JDK 1.5 Framework

A bit broader and deeper

Abstract Queue, Priority Queue

Rejected Purer Alternatives

Could avoid “OperationNot Supported”

Cost: Greatly increased footprint and complexity

The Java 2 CollectionsBruce Eckel, Thinking in Java, 2nd Ed.

Java 2 Collections, SimplifiedBruce Eckel, Thinking in Java, 2nd Ed.

UpdatableCollectionDoug Lea, “Overview of the Collections Classes”

Design Patterns:Resolving Tensions between Data Structures Library Design Goals

Iterator

Template Method

Support for Concurrency

Delegating Traversals

Application-Code Traversals Iterator Traversals

GOF Iterator

Iterators Enable “Extrafunctionality”

Iterators

Iterators with Extrafunctionality

Enumeration vs. Iterator

● Elements elements()● boolean

hasMoreElements()● Object nextElement()

● Iterator iterator()● boolean hasNext()● Object next()● remove()

GOF “Implementation Issues”

● Who controls the iterator?● Who defines the iterator? Iterators

may need privileged access.● Using polymorphic iterators● Additional iterator operations?● How robust is the iterator?

Who controls the Iterator? External vs. Internal Iterators

Internal Iterator

External Iterator

JDK 1.5 foreach

Prior to JDK 1.5:

public boolean containsAll

(Collection c) {

for (Iterator itr = c.iterator;

iter.hasNext(); ) {

if (!contains(iter.next()) {

return false;

}

}

return true;

}

JDK 1.5:

public boolean containsAll

(Collection c) {

for (Object o : c) {

if (!contains(o) {

return false;

}

}

return true;

}

Who defines the iterator? Iterators may need privileged access.

public abstract class AbstractList<E>

implements List<E> {....

private class Itr implements Iterator<E> {... }

private class ListItr implements ListIterator<E> {..}

}

Dual Hierarchy:

Collection

Iterator<E>

LinkedHashMap<K, V>

CollectionCollection

ArrayList<E>

LinkedHashIterator<E>

ListIterator<E>

Additional iterator operations?

Iterator<E>

next()hasNext()remove()

List Iterator<E>

previous()hasPrevious()nextIndex()previousIndex()set()add()

Using Polymorphic Iterators

● Iterator Collection.iterator() Factory methodpublic interface Iterable<T>

Iterator<T> iterator();

}

public interface Collection<E> extends Iterable<E> {

Iterator<E> iterator(); .....

}

● No reset() ... Just acquire a new iterator()!● Garbage collection targets providing better

support for cheap, short-lived, new objects

How robust is the Iterator?public abstract class AbstractList<E>

implements List<E> { ....

private class Itr implements Iterator<E> {

int expectedModCount = modCount;

.....

final void checkForComodification() {

if (modCount != expectedModCount)

throw new ConcurrentModificationException();

}

....

}

Template Method

AbstractList depends on polymorphic Iterator<E> operations

public abstract class AbstractList<E> implements List<E> { .... public boolean addAll(int index, Collection<? extends E> c) { boolean modified = false; Iterator<? extends E> e = c.iterator(); while (e.hasNext()) { add(index++, e.next()); modified = true; } return modified; }...}

Collections depend on polymorphic equals(), compareTo()

public abstract class AbstractList<E> implements List<E> { .... public int IndexOf(Object o) { .... ListIterator<? extends E> .... }... public int lastIndexOf(Object o) { .... ListIterator<? extends E> .... }...}

HashMap, HashSet Arrays.sort .... equals() .... .... compareTo() ...

Support for ConcurrencyVector, Hashtable made ALL methods synchronized JDK 1.2 Decorator for synchronized, unmodifiable collections:

Map<String, Circuit> ckts = Collections.SynchornizedMap(

new HashMap<String, Circuit>);java.util.concurrency:

Application-level Tools:

Concurrent HashMap, ConvurrentLinkedQueue

Futures

Executor

Core Mechanisms Available:

Exchanger

SynchronousQueue

CyclicBarrier

Semaphore