31.java collections framework ppt3
TRANSCRIPT
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 1/62
Java Collections Framework
9 January 2015 OSU CSE 1
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 2/62
Overview
• The Java Collections Framework (JCF)
is a group of interfaces and classes similarto the OSU CSE components
– The similarities will become clearly evident
from examples
– See Java libraries package j ava. ut i l
• There are some important differences, too,however, that deserve mention (at the
end)
9 January 2015 OSU CSE 2
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 3/62
Overview of Interfaces
9 January 2015 OSU CSE 3
Set List Queue
Collection
Sorted-
Set
Sorted-Map
Iterable
Deque
Navigable-
Set
Map
Navigable-
Map
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 4/62
Overview of Interfaces
9 January 2015 OSU CSE 4
Set List Queue
Collection
Sorted-
Set
Sorted-Map
Iterable
Deque
Navigable-
Set
Map
Navigable-
MapNote: Map does not
extend Col l ect i on;
but it is a “collection”.
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 5/62
Overview of Interfaces
9 January 2015 OSU CSE 5
Set List Queue
Collection
Sorted-
Set
Sorted-Map
Iterable
Deque
Navigable-
Set
Map
Navigable-
Map
I t er abl e is in j ava. l ang
(because of its intimateconnection to for-each loops),but I t er at or is in j ava. ut i l .
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 6/62
Overview of Interfaces
9 January 2015 OSU CSE 6
Set List Queue
Collection
Sorted-
Set
Sorted-Map
Iterable
Deque
Navigable-
Set
Map
Navigable-
Map
Subsequent slidesdiscuss only certain
interfaces.
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 7/62
The Col l ect i on<E>Interface
• 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, r emove,
cl ear ) are “optional”
9 January 2015 OSU CSE 7
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 8/62
The Set <E>Interface
• Essentially a finite set of E
• No r emoveAny or similar method, so you
must use i t er at or to iterate over a Set
– Recall (from I t er at or ): “The behavior of aniterator is unspecified if the underlying
collection is modified while the iteration is inprogress [except using I t er at or . r emove].”
• Many methods (including add, r emove,
cl ear ) are “optional”
9 January 2015 OSU CSE 8
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 9/62
The Li st <E>Interface• Essentially a string of E
• Access by position (similar to Sequencefrom OSU CSE components)
• Many methods (including add, r emove,
cl ear ) are “optional”
• Two interesting additional features:
– Sublist “views” of a Li st – A special two-way Li st I t er at or
9 January 2015 OSU CSE 9
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 10/62
The Li st <E>Interface• Essentially a string of E
• Access by position (similar to Sequencefrom OSU CSE components)
• Many methods (including add, r emove,
cl ear ) are “optional”
• Two interesting additional features:
– Sublist “views” of a Li st – A special two-way Li st I t er at or
9 January 2015 OSU CSE 10
How do you move forwardand backward through a Li st
from OSU CSE components?
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 11/62
The Queue<E>Interface• Essentially a string of E
• Access at ends (similar to Queue fromOSU CSE components)
• Here, add and r emove are not “optional”
– add is similar to enqueue for OSU CSE
components’ Queue
– r emove is similar to dequeue
• Curious names for other methods, e.g.,of f er , peek, pol l
9 January 2015 OSU CSE 11
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 12/62
The Map<K, V>Interface• Essentially a finite set of (K,V)
with the function property• No r emoveAny or similar method, so you
must use i t er at or (somewhat indirectly)
to iterate over a Map• Many methods (including put , r emove,
cl ear ) are “optional”
• Like Li st , a Map supports “views” of its
elements
9 January 2015 OSU CSE 12
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 13/62
Views in the JCF
• A view is a “subcollection” of a collection
– Not a copy of some of the elements, but rather
“a collection within a collection” that is
manipulated “in place”
• Views for Map:
– Keys: Set <K> keySet ( )
– Values: Col l ect i on<V> val ues( ) – Pairs: Set <Map. Ent r y<K, V>> ent r ySet ( )
9 January 2015 OSU CSE 13
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 14/62
Views in the JCF
• A view is a “subcollection” of a collection
– Not a copy of some of the elements, but rather“a collection within a collection” that is
manipulated “in place”
• Views for Map:
– Keys: Set <K> keySet ( )
– Values: Col l ect i on<V> val ues( ) – Pairs: Set <Map. Ent r y<K, V>> ent r ySet ( )
9 January 2015 OSU CSE 14
Map. Ent r y<K, V>in the JCF is
very similar to Map. Pai r <K, V>
in the OSU CSE components.
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 15/62
Example: Map<St r i ng, I nt eger > m
9 January 2015 OSU CSE 15
Code State
m = {("PB", 99),("BK", 42),
("SA", 42)}
Set <St r i ng> s =m. keySet ( ) ;
m = {("PB", 99),
("BK", 42),
("SA", 42)}
s = {"SA", "BK",
"PB"}
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 16/62
Example: Map<St r i ng, I nt eger > m
9 January 2015 OSU CSE 16
Code State
m = {("PB", 99),("BK", 42),
("SA", 42)}
Set <St r i ng> 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 St r i ng is immutable,but consider the potential
problems if it were not.
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 17/62
9 January 2015 OSU CSE 17
Code State
m = {("PB", 99),("BK", 42),
("SA", 42)}
Col l ect i on<I nt eger > c =m. val ues( ) ;
m = {("PB", 99),
("BK", 42),
("SA", 42)}
c = {42, 99, 42}
Example: Map<St r i ng, I nt eger > m
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 18/62
9 January 2015 OSU CSE 18
Code State
m = {("PB", 99),("BK", 42)}
Set <Map. Ent r y<St r i ng,
I nt eger>> s =m. ent r ySet ( ) ;
m = {("PB", 99),
("BK", 42)}
s = {("BK", 42),
("PB", 99)}
Example: Map<St r i ng, I nt eger > m
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 19/62
View “Backed By” Collection
• A view is backed by the underlying
collection, which means that if the view ismodified then the underlying (“backing”)
collection is also modified, and vice versa
– See Javadoc for supported modifications
– Be especially careful when iterating over a
view of a collection and trying to modify it
9 January 2015 OSU CSE 19
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 20/62
Example: Li st <I nt eger > s
9 January 2015 OSU CSE 20
Code State
s = <10, 7, 4, –2>
s. subLi st ( 1, 3) . cl ear ( ) ;
s = <10, –2>
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 21/62
9 January 2015 OSU CSE 21
Code State
m = {("PB", 99),
("BK", 42),
("SA", 42)}
m. val ues( ) . r emove( 42) ;
m = {("PB", 99),
("SA", 42)}
Example: Map<St r i ng, I nt eger > m
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 22/62
9 January 2015 OSU CSE 22
Code State
m = {("PB", 99),
("BK", 42),
("SA", 42)}
m. val ues( ) . r emove( 42) ;
m = {("PB", 99),
("SA", 42)}
Example: Map<St r i ng, I nt eger > mBecause r emove for
Col l ect i on (assuming it is
available for m. val ues!)removes one copy, we do notknow which pair remains in m.
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 23/62
Could r emove Cause Trouble?• The object (dynamic) type of
m. val ues( ) in the above code might bean implementation of Li st or of Queue
– But not of Set ; why not?
• The r emove being called is “optional” if
the object type of m. val ues( ) is a Li st
implementation, but not if it is a Queue – How can the client know what interface it
implements?
9 January 2015 OSU CSE 23
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 24/62
Could r emove Cause Trouble?• The object (dynamic) type of
m. val ues( ) in the above code might bean implementation of Li st or of Queue
– But not of Set ; why not?
• The r emove being called is “optional” if
the object type of m. val ues( ) is a Li st
implementation, but not if it is a Queue – How can the client know what interface it
implements?
9 January 2015 OSU CSE 24
The informal Javadoc for the val ues method says:
“The collection supports element removal, which
removes the corresponding mapping from the map, viathe I t er at or . r emove, Col l ect i on. r emove,
r emoveAl l , r et ai nAl l and cl ear operations. It does
not support the add or addAl l operations.”
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 25/62
Could r emove Cause Trouble?• The object (dynamic) type of
m. val ues( ) in the above code might bean implementation of Li st or of Queue
– But not of Set ; why not?
• The r emove being called is “optional” if
the object type of m. val ues( ) is a Li st
implementation, but not if it is a Queue – How can the client know what interface it
implements?
9 January 2015 OSU CSE 25
Since val ues returns an object whose dynamic type
“supports” r emove but not add, apparently that return
type implements a fictitious (phantom?) interface that isstronger than Col l ect i on, but different than all of Set ,
Li st , and Queue.
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 26/62
Iterating Over a Map• Because Map does not extend I t er abl e,
but Col l ect i on (hence Set ) doesextend I t er abl e, you can (only) iterate
over a Map using one of its three views:
– Keys: Set <K> keySet ( )
– Values: Col l ect i on<V> val ues( )
– Pairs: Set <Map. Ent r y<K, V>> ent r ySet ( )
9 January 2015 OSU CSE 26
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 27/62
Overview of Col l ect i on Classes
9 January 2015 OSU CSE 27
Collection
Iterable
Abstract-
Collection
There are no classes
that directly and fully
implementCol l ect i on.
Object
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 28/62
Abst r act Col l ect i on• Has code for many methods (shared, and
possibly overridden, by all laterimplementations of Col l ect i on) :
– add
– r emove
– cl ear
– . . .
9 January 2015 OSU CSE 28
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 29/62
Abst r act Col l ect i on• Has code for many methods (shared, and
possibly overridden, by all laterimplementations of Col l ect i on) :
– add
– r emove
– cl ear
– . . .
9 January 2015 OSU CSE 29
This method’s implementation here, forexample, “always throws an
Unsuppor t edOperat i onExcept i on”.
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 30/62
Overview of Set Classes
9 January 2015 OSU CSE 30
Set
HashSet
AbstractSet
TreeSet
Collection
Iterable
Abstract-
Collection
Object
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 31/62
Abst r act Set• Has code for these methods (shared, and
possibly overridden, by all laterimplementations of Set ):
– equal s
– hashCode
– r emoveAl l
9 January 2015 OSU CSE 31
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 32/62
HashSet• Uses hashing in the Set representation
• Has code for these methods (overridingthose in Abst r act Set ):
– add
– r emove
– cl ear
– cl one
9 January 2015 OSU CSE 32
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 33/62
HashSet• Uses hashing in the Set representation
• Has code for these methods (overridingthose in Abst r act Set ):
– add
– r emove
– cl ear
– cl one
9 January 2015 OSU CSE 33
The first three methods,
though “optional”, are
implemented here and do what
you should expect.
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 34/62
HashSet• Uses hashing in the Set representation
• Has code for these methods (overridingthose in Abst r act Set ):
– add
– r emove
– cl ear
– cl one
9 January 2015 OSU CSE 34
The cl one method “makes ashallow copy”, i.e., the
elements are not “cloned”;
which raises many questions.
Best practice: do not use it!
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 35/62
Tr eeSet• Uses a balanced binary search tree as
the Set representation• Has code for several methods (overriding
those in Abst r act Set )
9 January 2015 OSU CSE 35
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 36/62
Overview of Li st Classes
9 January 2015 OSU CSE 36
List
ArrayList
AbstractList
LinkedList
Collection
Iterable
Abstract-
Collection
Object
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 37/62
Abst r act Li st• Has code for many methods (shared, and
possibly overridden, by all laterimplementations of Li st )
• Similar to Abst r act Set but with code for
many more methods (because Li st has
many more potentially layered methodsthan Set )
9 January 2015 OSU CSE 37
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 38/62
Ar r ayLi st• Uses arrays in the Li st representation
• Has code for many methods (overridingthose in Abst r act Li st )
9 January 2015 OSU CSE 38
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 39/62
Li nkedLi st• Uses a doubly-linked list as the Li st
representation• Has code for many methods (overriding
those in Abst r act Li st )
• There is even more detail to the interfaces
and abstract classes related to
Li nkedLi st , which you can look up ifinterested
9 January 2015 OSU CSE 39
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 40/62
Overview of Map Classes
9 January 2015 OSU CSE 40
HashMap TreeMap
Map
AbstractMap
Object
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 41/62
Abst r act Map• Has code for many methods (shared, and
possibly overridden, by all laterimplementations of Map)
• Similar to Abst r act Set but with code for
many more methods (because Map has
many more potentially layered methodsthan Set )
9 January 2015 OSU CSE 41
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 42/62
HashMap• Uses hashing in the Map representation
• Has code for many methods (overridingthose in Abst r act Map)
9 January 2015 OSU CSE 42
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 43/62
Tr eeMap• Uses a balanced binary search tree as
the Map representation• Has code for several methods (overriding
those in Abst r act Map)
9 January 2015 OSU CSE 43
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 44/62
JCF Algorithms: Col l ect i ons• A number of useful algorithms (and simple
but convenient utilities) to processcollections are static methods in theclass Col l ect i ons, e.g.:
– sort
– reverse
– mi n, max
– shuf f l e
– f r equency
9 January 2015 OSU CSE 44
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 45/62
JCF Algorithms: Col l ect i ons• A number of useful algorithms (and simple
but convenient utilities) to processcollections are static methods in theclass Col l ect i ons, e.g.:
– sort
– reverse
– mi n, max
– shuf f l e
– f r equency
9 January 2015 OSU CSE 45
Notice that the classCol l ect i ons is different
from the interface
Col l ect i on, and inparticular it does not
implement that interface!
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 46/62
JCF Utilities: Ar r ays• A number of useful algorithms (and simple
but convenient utilities) to process built-inarrays are static methods in the classAr r ays, e.g.:
– sort
– f i l l
– deepEqual s
– deepHashCode
– deepToSt r i ng
9 January 2015 OSU CSE 46
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 47/62
OSU CSE vs. JCF Components• The OSU CSE components are similar in
design to the JCF interfaces and classes• Though some differences can be
attributed to pedagogical concerns, there
are other important technical differences,
too!
9 January 2015 OSU CSE 47
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 48/62
Difference #1: Level of Formalism• JCF interfaces include only informal
Javadoc comments for contracts (ratherthan using explicit mathematical models
and requires/ensures clauses)
– JCF descriptions and contracts use similarterms, though; e.g.,“collections” may:
• be “ordered” or “unordered”
• “have duplicates” or “not have duplicates”
9 January 2015 OSU CSE 48
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 49/62
Difference #1: Level of Formalism• JCF interfaces include only informal
Javadoc comments for contracts (ratherthan using explicit mathematical models
and requires/ensures clauses)
– JCF descriptions and contracts use similarterms, though; e.g.,“collections” may:
• be “ordered” or “unordered”
• “have duplicates” or “not have duplicates”
9 January 2015 OSU CSE 49
JCF j ava. ut i l . Set <E>:
boolean add( E e) Adds the specified element to this set if it is not already present (optional operation). More formally, adds thespecified element e to this set if the set contains no element e2 such that
( e==nul l ? e2==nul l : e. equal s( e2) ) . If this set already contains the element, the call leaves the set
unchanged and returns f al se. 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 particularelement, including nul l , and throw an exception, as described in the specification for Col l ect i on. add.
Individual set implementations should clearly document any restrictions on the elements that they may contain.
Throws:Unsuppor t edOper at i onExcept i on - if the add operation is not supported by this set
Cl assCast Except i on - if the class of the specified element prevents it from being added to this set
Nul l Poi nt erExcept i on - if the specified element is null and this set does not permit null elements
I l l egal Ar gument Except i on - if some property of the specified element prevents it from being added to this
set
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 50/62
Difference #1: Level of Formalism• JCF interfaces include only informal
Javadoc comments for contracts (ratherthan using explicit mathematical models
and requires/ensures clauses)
– JCF descriptions and contracts use similarterms, though; e.g.,“collections” may:
• be “ordered” or “unordered”
• “have duplicates” or “not have duplicates”
9 January 2015 OSU CSE 50
OSU CSE component s. set . Set <T>:
void add( T x) Adds x to this.
Aliases:reference x
Updates:this
Requires:x is not in this
Ensures:this = #this union {x}
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 51/62
Difference #1: Level of Formalism• JCF interfaces include only informal
Javadoc comments for contracts (ratherthan using explicit mathematical models
and requires/ensures clauses)
– JCF descriptions and contracts use similarterms, though; e.g.,“collections” may:
• be “ordered” or “unordered”
• “have duplicates” or “not have duplicates”
9 January 2015 OSU CSE 51
Hypothetical OSU CSE component s. set . Set <T>:
boolean add( T x)
Can you write a formal contract for the add method as it
is designed in j ava. ut i l . Set ?
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 52/62
Difference #1: Level of Formalism• JCF interfaces include only informal
Javadoc comments for contracts (ratherthan using explicit mathematical models
and requires/ensures clauses)
– JCF descriptions and contracts use similarterms, though; e.g.,“collections” may:
• be “ordered” or “unordered”
• “have duplicates” or “not have duplicates”
9 January 2015 OSU CSE 52
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 apparently
contradictory to, the method descriptions; e.g.:• i t er at or for Sor t edSet• a few methods for Pr i or i t yQueue
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 53/62
Difference #2: Parameter Modes• JCF interfaces do not have any notion of
parameter modes (rather than using themin contracts to help clarify and simplify
behavioral descriptions)
– If the JCF used parameter modes, though, thedefault mode also would be “restores”, as with
the OSU CSE components
9 January 2015 OSU CSE 53
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 54/62
Difference #3: Aliasing• JCF interfaces almost never explicitly
mention aliasing (rather than advertisingaliasing when it may arise)
– JCF components also are not designed to try
to avoid aliasing whenever possible, as theOSU CSE components are
9 January 2015 OSU CSE 54
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 55/62
Difference #4: Null• JCF interfaces generally permit null
references to be stored in collections(rather than having a blanket prohibition
against null references)
– JCF components do, however, sometimesinclude warnings against null references,
which the OSU components always prohibit
9 January 2015 OSU CSE 55
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 56/62
Difference #5: Optional Methods• JCF interfaces generally have “optional”
methods (rather than requiring all methodsto behave according to their specifications
in all implementations)
– JCF implementations of the same interfaceare therefore not plug-compatible: “optional”
methods have bodies, but calling one might
simply throw an exception:Unsuppor t edOper at i onExcept i on
9 January 2015 OSU CSE 56
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 57/62
Difference #6: Copy Constructors• By convention, every class in the JCF has
two “standard” constructors: – A no-argument constructor
– A conversion constructor that “copies”
references to the elements of its argument,which is another JCF collection
9 January 2015 OSU CSE 57
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 58/62
Difference #6: Copy Constructors• By convention, every class in the JCF has
two “standard” constructors: – A no-argument constructor
– A conversion constructor that “copies”
references to the elements of its argument,which is another JCF collection
9 January 2015 OSU CSE 58
This no-argument constructor
creates an empty collection.
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 59/62
Difference #6: Copy Constructors• By convention, every class in the JCF has
two “standard” constructors: – A no-argument constructor
– A conversion constructor that “copies”
references to the elements of its argument,which is another JCF collection
9 January 2015 OSU CSE 59
Presumably, “copying” from a
collection that may have
duplicates, to one that may not,simply removes extra copies.
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 60/62
Difference #7: Exceptions• Violation of what might have been
considered a precondition leads to aspecific exception being thrown (rather
than simply a conceptual contract
violation, which might or might not bechecked using assert)
– Example: an attempt to remove an element
from an empty Queue is specified to result ina NoSuchEl ement Except i on
9 January 2015 OSU CSE 60
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 61/62
Difference #8: Kernel Methods• A single JCF interface usually contains all
methods applicable to a type (rather than“kernel” methods being separated into a
separate interface from all other methods)
– JCF uses abstract classes, however, toprovide default implementations of methods
that presumably would be implemented in
abstract classes in the OSU CSE components – Other JCF methods are like “kernel” methods
9 January 2015 OSU CSE 61
7/23/2019 31.Java Collections Framework Ppt3
http://slidepdf.com/reader/full/31java-collections-framework-ppt3 62/62
Resources• The Collections Framework (from Oracle)
– http://docs.oracle.com/javase/7/docs/technotes/guides/collections/
• Effective Java, Second Edition – http://proquest.safaribooksonline.com.proxy.lib.ohio-
state.edu/book/programming/java/9780137150021
9 January 2015 OSU CSE 62