Java Collections

The Problem Collections Solve: Arrays Don't Resize

If you've followed the tutorials in order, you've already hit the limitation. By the time you need to store an unknown number of items — processing lines from a file, collecting search results, building a list of employees — Java's basic arrays become awkward:

// You have to guess the maximum size upfront
String[] lines = new String[1000];  // What if the file has 1001 lines?

int count = 0;
for (String line : allLines) {
    if (count >= lines.length) {
        // Resize manually — error-prone and tedious
        lines = Arrays.copyOf(lines, lines.length * 2);
    }
    lines[count++] = line;
}

// Or: count first, then create the right-sized array
// (requires reading the file twice — wasteful for large files)

Collections solve this with a simple idea: a data structure that grows automatically. You just call add(item) and the internal storage resizes itself when needed. You never think about array sizes again.

List<String> lines = new ArrayList<>();

for (String line : allLines) {
    lines.add(line);  // That's it. No sizing, no resizing, no counting.
}

The Collections Framework is Java's unified architecture for these resizable data structures. It provides interfaces that define what a data structure does (a List is an ordered collection, a Map stores key-value pairs) and concrete classes that implement them (ArrayList, HashMap). This separation is central to how real Java code is written.

The Interfaces vs. Implementations Pattern

This is the most important concept in the Collections Framework, and the one that confuses newcomers the most. It's a two-level design:

In practice, this means you write:

// The type is the INTERFACE, not the implementation
public void processNames(List<String> names) {
    for (String name : names) {
        System.out.println(name.toUpperCase());
    }
}

// The object is the IMPLEMENTATION
List<String> names = new ArrayList<>();

Why does this matter? Because you can change the implementation later without touching the method:

// Same method, same interface — works with LinkedList too
List<String> names = new LinkedList<>();

// If a method takes List, it accepts ArrayList, LinkedList, Vector,
// or any future List implementation — without changes.

This pattern — writing code against interfaces — is also how Spring Boot works. When Spring injects a List<Employee> into your service, you don't care whether it's an ArrayList or a LinkedList. The framework decides. Your code stays decoupled from implementation details.

Before You Start

You should complete the Object-Oriented Programming section first. Specifically:

• Classes and Objects — Collections hold objects, so you need to be comfortable creating classes with fields, constructors, and methods. You'll be putting Employee objects into an ArrayList and using Employee objects as HashMap keys.
• Inheritance — Not directly required for ArrayList and HashMap, but the concept of a type hierarchy helps you understand why ArrayList implements List, and why you can pass an ArrayList where a List is expected.

You should also be comfortable with basic generics syntax: List<String>, Map<String, Integer>. The tutorials introduce generics as they go, but if seeing angle brackets in type names is completely new to you, read the short "Generics at a Glance" section below first.

Generics at a Glance

Generics let you specify what type of objects a collection can hold. Without them, every collection would hold Object, and you'd need to cast every element:

List names = new ArrayList();
names.add("Alice");
names.add("Bob");

// No type safety — this compiles but crashes at runtime:
names.add(42);  // Integer in a List of Strings — no compile error!

// You have to cast every element when retrieving:
String first = (String) names.get(0);

List<String> names = new ArrayList<>();
names.add("Alice");
names.add("Bob");

// This is a COMPILE ERROR — caught before the program runs:
names.add(42);  // required type: String, found: Integer

// No casting needed:
String first = names.get(0);

The <String> in ArrayList<String> is a type parameter. It tells the compiler: "this list only accepts Strings." The same syntax applies to HashMap<String, Integer> — two type parameters because a map has a key type and a value type.

Tutorials — Study in This Order

After Completing These Tutorials

What's Not Covered Here (and Why)

The Java Collections Framework has dozens of types. We focus on the two you'll use in almost every program. Here's what's deferred and when you'll encounter it:

Where to Go After Collections