Published: May 14, 2001
By Richard G. Baldwin
Java Programming, Lecture Notes # 1352
The purpose of this miniseries is to help you learn the essential features of Object-Oriented data structures in Java using the Collections Framework.
Supplementary material
I recommend that you also study the other lessons in my extensive collection of online Java tutorials. You will find those lessons published at Gamelan.com. However, as of the date of this writing, Gamelan doesn't maintain a consolidated index of my Java tutorial lessons, and sometimes they are difficult to locate there. You will find a consolidated index at Baldwin's Java Programming Tutorials.
The index on my site provides links to the lessons at Gamelan.com.
In this lesson, I will discuss how elements are stored in a collection, and why it is often necessary to use a downcast when retrieving and processing those elements.
I will discuss the advantages of passing collections between methods as type Collection.
I will summarize the core interfaces in the Collections Framework and show you how they are related.
I will very briefly discuss the concrete implementations of the interfaces that are provided by the framework. (I will discuss those implementations in much more detail in subsequent lessons.)
And finally, I will introduce you to the three kinds of things that are part of a collections framework.
Just to see if you are awake today, let's start with a little quiz.
What is a collection insofar as Java programming is concerned?
Collection is the name of a Java interface. This interface is an integral part of the Java Collections Framework. In fact, as of JDK 1.3, it is one of two top-level interfaces in the framework. The other top-level interface in the framework is named Map.
According to The Java Tutorial from Sun, a collection (sometimes called a container) is also an object that groups multiple elements into a single unit.
Typical collection objects might contain information about employees in the company telephone book, all the purchase orders issued during the past year, or the transactions occurring in a person's checking account.
Slightly different terminology
Note that this terminology may be somewhat different from what you are accustomed to. For example, if you speak of your coin collection, you are probably speaking about the actual coins rather than the container that holds the coins.
This is an important distinction. The usage of the term collection in the Collection Framework usually refers to the container and not to the contents of the container. In the framework, the contents are usually referred to as elements.
Store references rather than objects
The collections in the framework always store references to objects, rather than storing the objects themselves. One consequence of this is that primitive values cannot be stored in a collection without first encapsulating them in an object. (Standard wrapper classes are provided for encapsulating all primitive types.)
Stored as type Object
Furthermore, the references are always stored as type Object. Thus, when you retrieve an element from a collection, you frequently need to downcast it before you can gain access to the members of the object to which the reference refers.
Moving data among methods
In addition to their use for storing, retrieving, and manipulating data, collections are also used to move data among methods.
One of the primary advantages of the Collections Framework is the ability to pass a collection to a method as the generic interface type Collection. The receiving method doesn't need to know the actual type of the object referred to by the incoming reference in order to invoke its methods.
Polymorphic behavior
The receiving method can invoke (on the reference to the Collection object) any of the methods declared in the Collection interface, with confidence that the behavior of the method will be appropriate for the actual type of Collection object involved. (That is polymorphic behavior.)
Core collection interfaces
If you have been working with the framework, you might be inclined to think that all of the interfaces in the following list are members of the core collection interfaces.
While the Iterator interface is heavily used in conjunction with collections, according to The Java Tutorial from Sun, it is not one of the core collection interfaces.
The core collection interfaces identified by the Sun book are shown below, with indentation showing the superinterface-subinterface relationships among the interfaces.
You should probably commit the above list of interfaces and their relationships to memory. You might find that helpful when navigating the Sun documentation.
Concrete implementations
In addition to interfaces, the framework provides several concrete implementations of the interfaces defined in the framework. (A concrete implementation is a class that implements one or more of the interfaces.)
Are you still awake? If so, see if you can answer the following question.
True or False? Each of the following classes provides an implementation of one of the interfaces that make up the Java Collections Framework. If False, which items don't belong in the list.
Iterator is not a class
To begin with, Iterator is not a class. I told you that a couple of paragraphs back. It is an interface. Therefore, it has no place on the above list of classes.
What about Attributes and RenderingHints?
You may also have wondered if the classes named Attributes and RenderingHints belong on the list. Note that I didn't restrict the above list to only those classes that might be considered part of the framework, so this was sort of a trick question. (Of course you could have looked them up in the Sun documentation just like I did.)
While these two classes are not really a part of the core Java Collections Framework, they do implement interfaces that are part of the framework.
The RenderingHints class implements the Map interface, and is used in conjunction with the Graphics2D class. The Attributes class also implements the Map interface,
What is a Collections Framework?
According to The Java Tutorial from Sun, "A collections framework is a unified architecture for representing and manipulating collections. All collections frameworks contain three things."
Those three things are:
Java Collection objects don't store objects or primitive values directly. Rather, they store references to objects. Further, all such references are stored as the type Object. This often leads to the later need to downcast the reference in order to gain access to the members of the object to which it refers.
If you need to store primitive values in a collection, you will first need to wrap those values in appropriate objects. Standard wrapper classes are provided for all the primitive types.
Collections are not only useful for storing and retrieving data, they are also useful for moving data among methods.
Because a collection can be passed to a method as type Collection, all of the methods declared in the Collection interface can be invoked on the incoming reference in a polymorphic manner.
In addition to the interfaces defined in the Collections Framework, the framework also provides various concrete implementations of the interfaces for most of the commonly-used data structures. This makes it possible for you to conveniently use the framework without the requirement to define new Collection classes.
As of JDK 1.3, there are six core interfaces in the framework. Although the Iterator interface is often used with collections, it is not one of the core interfaces.
I ended the lesson by telling you that there are basically three things in a collections framework: interfaces, implementations, and algorithms.
Copyright 2000, Richard G. Baldwin. Reproduction in whole or in part in any form or medium without express written permission from Richard Baldwin is prohibited.
Richard has participated in numerous consulting projects involving Java, XML, or a combination of the two. He frequently provides onsite Java and/or XML training at the high-tech companies located in and around Austin, Texas. He is the author of Baldwin's Java Programming Tutorials, which has gained a worldwide following among experienced and aspiring Java programmers. He has also published articles on Java Programming in Java Pro magazine.
Richard holds an MSEE degree from Southern Methodist University and has many years of experience in the application of computer technology to real-world problems.
-end-