31.java collections framework

8/12/2019 31.Java Collections Framework

1/62

Java Collections Framework

24 April 2013 OSU CSE 1


2/62

Overview

The Java Collections Framework (JCF)is a group of interfaces and classes similar

to the OSU CSE components

The similarities will become clearly evidentfrom examples

See Java libraries package java.util There are some important differences, too,

however, that deserve mention (at the

end)



3/62

Overview of Interfaces


Set List Queue

Collection

Sorted-Set

Sorted-Map

Iterable

Deque

Navigable-Set

Map

Navigable-Map


4/62



Set List Queue

Collection

Sorted-

Set

Sorted-Map

Iterable

Deque

Navigable-Set

Map

Navigable-

Map

Note: Mapdoes notextend Collection;

but it is a collection.


5/62



Set List Queue

Collection

Sorted-

Set

Sorted-Map

Iterable

Deque

Navigable-Set

Map

Navigable-

Map

Iterableis in java.lang

(because of its intimateconnection to for-each loops),

but Iteratoris in java.util.


6/62



Set List Queue

Collection

Sorted-

Set

Sorted-Map

Iterable

Deque

Navigable-Set

Map

Navigable-

Map

Subsequent slidesdiscuss only certain

interfaces.


7/62

The CollectionInterface

Essentially a finite multiset of E No direct/efficient way to ask how many

copies of a given element there are

Two interesting methods to create arrays ofthe elements

Many methods (including add, remove,clear) are optional



8/62

The SetInterface

Essentially a finite set of E No removeAnyor similar method, so you

must use iteratorto iterate over a Set

Recall (from Iterator): The behavior of aniterator is unspecified if the underlying

collection is modified while the iteration is in

progress [except using Iterator.remove]. Many methods (including add, remove,clear) are optional



9/62

The ListInterface

Essentially a string of EAccess by position (similar to Sequence

from OSU CSE components)


Two interesting additional features: Sublist views of a ListA special two-way ListIterator



10/62

The ListInterface

Essentially a string of EAccess by position (similar to Sequence

from OSU CSE components)


Two interesting additional features: Sublist views of a ListA special two-way ListIterator


How do you move forwardand backward through a List

from OSU CSE components?


11/62

The QueueInterface

Essentially a string of EAccess at ends (similar to Queuefrom

OSU CSE components)

Here, addand removeare notoptionaladdis similar to enqueuefor OSU CSE

components Queue

removeis similar to dequeue Curious names for other methods, e.g.,offer, peek, poll



12/62

The MapInterface

Essentially a finite set of (K,V)with the function property

No removeAnyor similar method, so youmust use iterator(somewhat indirectly)to iterate over a Map

Many methods (including put, remove,clear) are optional

Like List, a Mapsupports views of itselements



13/62

Views in the JCF

A viewis a subcollection of a collection Not a copyof some of the elements, but rather

a collection within a collectionthat is

manipulated in place

Views for Map: Keys: Set keySet() Values: Collection values() Pairs: Set entrySet()



14/62

Views in the JCF

A viewis a subcollection of a collection Not a copyof some of the elements, but rather

a collection within a collectionthat is

manipulated in place

Views for Map: Keys: Set keySet() Values: Collection values() Pairs: Set entrySet()


Map.Entryin the JCF is

very similar to Map.Pairin the OSU CSE components.


15/62

Example: Map m


Code Statem = {("PB", 99),

("BK", 42),

("SA", 42)}

Set s =

m.keySet();

m = {("PB", 99),

("BK", 42),("SA", 42)}

s = {"SA", "BK",

"PB"}


16/62

Example: Map m



("BK", 42),

("SA", 42)}

Set s =

m.keySet();

m = {("PB", 99),

("BK", 42),("SA", 42)}

s = {"SA", "BK",

"PB"}

Note all the aliases here!There is no problem in this case

because Stringis immutable,

but consider the potential

problems if it were not.


17/62



("BK", 42),

("SA", 42)}

Collection c =

m.values();

m = {("PB", 99),

("BK", 42),("SA", 42)}

c = {42, 99, 42}

Example: Map m


18/62


Code State

m = {("PB", 99),

("BK", 42)}

Set s =

m.entrySet();

m = {("PB", 99),

("BK", 42)}s = {("BK", 42),

("PB", 99)}

Example: Map m


19/62

View Backed By Collection

A view is backed by the underlyingcollection, which means that if the view is

modified then the underlying (backing)

collection is also modified, and vice versa

See Javadoc for supported modifications Be especially careful when iterating over a

view or a collection and trying to modify it



20/62

Example: List s


Code State

s =

s.subList(1,3).clear();

s =


21/62


Code State

m = {("PB", 99),

("BK", 42),

("SA", 42)}

m.values().remove(42);

m = {("PB", 99),

("SA", 42)}

Example: Map m


22/62


Code State

m = {("PB", 99),

("BK", 42),

("SA", 42)}

m.values().remove(42);

m = {("PB", 99),

("SA", 42)}

Example: Map m

Because removeforCollection(assuming it is

available for m.values!)

removes one copy, we do not

know which pair remains in m.


23/62


24/62

Could removeCause Trouble?

The object (dynamic) type ofm.values()in the above code might be

an implementation of Listor of Queue

But not of Set; why not? The removebeing called is optional if

the object type of m.values()is a List

implementation, but not if it is a Queue How can the client know what interface it

implements?


The informal Javadoc for the valuesmethod says:The collection supports element removal, which

removes the corresponding mapping from the map, via

the Iterator.remove, Collection.remove,

removeAll, retainAlland clearoperations. It does

not support the addor addAlloperations.


25/62

Could removeCause Trouble?

The object (dynamic) type ofm.values()in the above code might be

an implementation of Listor of Queue

But not of Set; why not? The removebeing called is optional if

the object type of m.values()is a List

implementation, but not if it is a Queue How can the client know what interface it

implements?


Since valuesreturns an object whose dynamic typesupports removebut not add, apparently that return

type implements a fictitious (phantom?) interface that is

stronger than Collection, but different than all of Set,

List, and Queue.


26/62

Iterating Over a Map

Because Mapdoes notextend Iterable,but Collection(hence Set) does

extend Iterable, you can (only) iterate

over a Mapusing one of its three views: Keys: Set keySet() Values: Collection values() Pairs: Set entrySet()



27/62

Overview of CollectionClasses


Collection

Iterable

Abstract-Collection

There are no classes

that directly and fullyimplement

Collection.

Object


28/62

AbstractCollection

Has code for many methods (shared, andpossibly overridden, by all later

implementations of Collection) :

addremoveclear...



29/62

AbstractCollection


implementations of Collection) :

addremoveclear...


This methods implementation here, forexample, always throws an

UnsupportedOperationException.


30/62

Overview of SetClasses


Set

HashSet

AbstractSet

TreeSet

Collection

Iterable

Abstract-Collection

Object


31/62

AbstractSet

Has code for these methods (shared, andpossibly overridden, by all later

implementations of Set):

equalshashCoderemoveAll



32/62


33/62

HashSet

Uses hashingin the Setrepresentation Has code for these methods (overriding

those in AbstractSet):

addremoveclearclone


The first three methods,though optional, are

implemented here and do what

you should expect.


34/62

HashSet

Uses hashingin the Setrepresentation Has code for these methods (overriding

those in AbstractSet):

addremoveclearclone


The clonemethod makes ashallow copy, i.e., the

elements are not cloned;

which raises many questions.Best practice: do not use it!


35/62

TreeSet

Uses a balanced binary search tree asthe Setrepresentation

Has code for several methods (overridingthose in AbstractSet)



36/62

Overview of ListClasses


List

ArrayList

AbstractList

LinkedList

Collection

Iterable

Abstract-Collection

Object


37/62

AbstractList


implementations of List)

Similar to AbstractSetbut with code formany more methods (because Listhas

many more potentially layered methods

than Set)



38/62

ArrayList

Uses arraysin the Listrepresentation Has code for many methods (overriding

those in AbstractList)



39/62

LinkedList

Uses a doubly-linked listas the Listrepresentation

Has code for many methods (overridingthose in AbstractList)

There is even more detail to the interfacesand abstract classes related to

LinkedList, which you can look up ifinterested



40/62

Overview of MapClasses


HashMap TreeMap

Map

AbstractMap

Object


41/62

AbstractMap


implementations of Map)

Similar to AbstractSetbut with code formany more methods (because Maphas

many more potentially layered methods

than Set)



42/62

HashMap

Uses hashingin the Maprepresentation Has code for many methods (overriding

those in AbstractMap)



43/62

TreeMap

Uses a balanced binary search tree asthe Maprepresentation

Has code for several methods (overridingthose in AbstractMap)



44/62

JCF Algorithms: Collections

A number of useful algorithms (and simplebut convenient utilities) to process

collections are static methods in the

class Collections, e.g.:sortreversemin, maxshufflefrequency



45/62

JCF Algorithms: Collections

A number of useful algorithms (and simplebut convenient utilities) to process

collections are static methods in the

class Collections, e.g.:sortreversemin, maxshufflefrequency


Notice that the classCollectionsis different

from the interface

Collection, and in

particular it does not

implement that interface!


46/62

JCF Utilities: Arrays

A number of useful algorithms (and simplebut convenient utilities) to process built-in

arrays are static methods in the class

Arrays, e.g.:sortfilldeepEqualsdeepHashCodedeepToString



47/62

OSU CSE vs.JCF Components

The OSU CSE components are similar indesign to the JCF interfaces and classes

Though some differences can beattributed to pedagogical concerns, there

are other important technical differences,

too!



48/62

Difference #1: Level of Formalism

JCF interfaces include only informalJavadoc comments forcontracts (rather

than using explicit mathematical models

and requires/ensures clauses) JCF descriptions and contracts use similar

terms, though; e.g.,collections may:

be ordered or unordered

have duplicates or not have duplicates



49/62









JCF java.util.Set:

booleanadd(E e)Adds the specified element to this set if it is not already present (optional operation). More formally, adds thespecified element eto this set if the set contains no element e2such that

(e==null ? e2==null : e.equals(e2)). If this set already contains the element, the call leaves the setunchanged and returns false. In combination with the restriction on constructors, this ensures that sets never

contain duplicate elements.

The stipulation above does not imply that sets must accept all elements; sets may refuse to add any particular

element, including null, and throw an exception, as described in the specification for Collection.add.Individual set implementations should clearly document any restrictions on the elements that they may contain.

Throws:

UnsupportedOperationException- if the add operation is not supported by this setClassCastException- if the class of the specified element prevents it from being added to this setNullPointerException- if the specified element is null and this set does not permit null elementsIllegalArgumentException- if some property of the specified element prevents it from being added to this

set


50/62


51/62









HypotheticalOSU CSE components.set.Set:

booleanadd(T x)

Can you write a formal contract for the addmethod as it

is designed in java.util.Set?


52/62









Warning about the JCF documentation:The interface/class summary at the top of the

Javadoc-generated page sometimes contains

information that is missing from, or even apparentlycontradictory to, the method descriptions; e.g.:

iteratorfor SortedSet a few methods for PriorityQueue


53/62

Difference #2: Parameter Modes

JCF interfaces do not have any notion ofparameter modes (rather than using them

in contracts to help clarify and simplify

behavioral descriptions) If the JCF used parameter modes, though, the

default mode also would be restores, as with

the OSU CSE components



54/62

Difference #3: Aliasing

JCF interfaces almost never explicitlymention aliasing (rather than advertising

aliasing when it may arise)

JCF components also are notdesigned to tryto avoid aliasing whenever possible, as the

OSU CSE components are



55/62

Difference #4: Null

JCF interfaces generally permit nullreferences to be stored in collections

(rather than having a blanket prohibition

against null references) JCF components do, however, sometimes

include warnings against null references,

which the OSU components always prohibit



56/62

Difference #5: Optional Methods

JCF interfaces generally have optionalmethods (rather than requiring all methods

to behave according to their specifications

in all implementations) JCF implementations of the same interface

are therefore notplug-compatible: optional

methods have bodies, but calling one mightsimply throw an exception:

UnsupportedOperationException



57/62

Difference #6: Copy Constructors

By convention, every class in the JCF hastwo standard constructors:

A default constructorA conversion constructorthat copies

references to the elements of its argument,

which is another JCF collection



58/62







This no-argument constructor

creates an empty collection.


59/62







Presumably, copying from a

collection that may haveduplicates, to one that may not,

simply removes extra copies.


60/62


61/62

Difference #8: Kernel Methods

A single JCF interface usually contains allmethods applicable to a type (rather than

kernel methods being separated into a

separate interface from all other methods) JCF uses abstract classes, however, to

provide default implementations of methods

that presumably would be implemented inabstract classes in the OSU CSE components

Other JCF methods are like kernel methods24 April 2013 OSU CSE 61


62/62

31.java collections framework

Documents