Over the course of the last couple weeks, I’ve been messing around with the Java Collections Framework. Specifically, I’ve had to learn a few things about the framework in order to use some of the concrete implementations in a school project.  The Java Collections Framework has a lot of moving pieces, and the Oracle tutorials can be a little confusing.  Here is my attempt to demonstrate a simple way to take advantage of the framework.

Overview

The Java Collections Framework is a group of interfaces and classes that make it easy to deal with data structures. A data structure is just a fancy way of referring to structured information. There are many different types of data structures, and an examination of those types is beyond the scope of this post. If you’re interested, here’s one place you can start. In addition to classically recognized data structures, you’re also free to invent your own type of data structure that is capable of meeting your particular needs in a given project. Here’s the process I go through when working on a Java project that could benefit from use of the collections framework.

Step 1: Recognize the Need

It’s tough to use a tool if you can’t recognize the situations where it’s needed. In this case, if I find myself storing, accessing, and manipulating a collection of objects, then this is probably a good time to consider using the collections framework.

Step 2: Choose a Structure

Next, I pick from one of four high-level data structures that are implemented in the Collections Framework: Set, List, Queue, and Map. If you don’t know what these are, check my earlier link about data structures. However, here’s a very brief description of each.

• Set - A bucket that contains a bunch of unique items.
• List - A bucket that contains a bunch of items.  Duplicates are allowed.
• Queue - A bucket that contains a bunch of items that are waiting to do something.
• Map - A bucket that acts like a dictionary.  Each item has a key (the dictionary “word”) and a value (the “definition”).  Keys have to be unique.

I’ve found that 80% of the problems I’ve encountered can be handled by using some flavor of these four structures.

Step 3: Choose an Implementation

The Java Collections Framework is made up of a bunch of interfaces, abstract classes, and actual implementations of those classes.  They are arranged in a hierarchy so that you can use some or all of what’s offered to meet your needs.  However, the most straight-forward way to use the framework is to simply use the actual implementations of the classes. That’s the approach I’ve taken, and it works almost all of the time.  It’s an approach that won’t always work, but I prefer to take the simplest, most straight-forward route, and then go back and refactor if I need to make changes.

That being said, here’s how I decide which class implementation to use for each data structure.

Set

Does it need to be ordered?  If not, use a HashSet.  Is the order in which they were added to the set sufficient for my ordering needs?  If yes, use a LinkedHashSet.  Otherwise, use a TreeSet.

List

Always default to using an ArrayList.  It’s the best for inserting and removing elements at the end of the list.  However, if I need to insert or remove elements in the middle of the list, use a LinkedList.

Queue

Default to using a LinkedList for any standard type of queue (FIFO, LIFO, etc.).  If I need the queue to order its elements in some other way, use a PriorityQueue.

Map

Does it need to be ordered?  If not, use a HashMap.  Is the order in which they were added to the map sufficient for my ordering needs?  If yes, use a LinkedHashMap.  Otherwise, use a TreeMap.

Summary

If you choose your collection implementation using the above considerations, you will (usually) end up using the most appropriate and most efficient collection for your needs.  There are always exceptions to the rule, but this post was meant to be a high-level look at the framework.  I know I didn’t talk about the mechanics of sorting, iterating, or synchronization.  Those are discussions for another day.