Unmodifiable vs Immutable Collections

Java has two kinds of "read-only" collections, and they are often confused. An unmodifiable view, created with Collections.unmodifiableList(list), blocks changes made through the view, but it still reflects changes made to the original list behind it. An immutable collection, created with List.of or List.copyOf, has no original behind it, so its contents never change. In this lesson, you will see the difference in code and learn when to use each.

Example: A View vs a Copy

Let's see an example where the original list changes after both are created.

import java.util.ArrayList;
import java.util.Collections;
import java.util.List;
 
public class ViewVsCopy {
    public static void main(String[] args) {
        List<String> original = new ArrayList<>(List.of("Navika", "Srihitha"));
 
        List<String> view = Collections.unmodifiableList(original);
        List<String> copy = List.copyOf(original);
 
        original.add("Advitha");
 
        System.out.println("original: " + original);
        System.out.println("view:     " + view);
        System.out.println("copy:     " + copy);
 
        try {
            view.add("Anamaneni");
        } catch (UnsupportedOperationException e) {
            System.out.println("view.add rejected");
        }
    }
}

original: [Navika, Srihitha, Advitha]
view:     [Navika, Srihitha, Advitha]
copy:     [Navika, Srihitha]
view.add rejected

Explanation: Both the view and the copy reject add. But when the original list gained Advitha, the view showed it too, because the view is just a read-only window onto the original. The copy didn't change, because it holds its own elements.

Differences

When to Use Each

• Use an unmodifiable view when a class wants to let callers see live data that the class itself keeps updating, without letting them change it. For example, a playlist object can return a read-only view of its songs.
• Use an immutable copy when you want a snapshot that will never change, for example storing a list passed into a constructor, or sharing data between threads.

Common Mistakes

Assuming Collections.unmodifiableList makes the data safe from all changes. Anyone holding the original list can still change it.

Wrapping a list twice to "make it more immutable". It's still a view of the same original.

Calling List.copyOf on an already-immutable list and expecting a new copy. It may return the same object, which is fine because it can't change.

Interview Corner

Practice

1. Easy: Repeat the example with a Map: create an unmodifiable view and a Map.copyOf, then put a new key in the original and print all three.
2. Harder: Write a Course class that keeps an internal ArrayList of students, offers addStudent, and exposes students() as an unmodifiable view. Show that a caller sees new students but can't add any.

Key Takeaways