Collections.unmodifiableList vs List.copyOf in Java
Quick Answer: Collections.unmodifiableList in Java creates a read-only view wrapper over an existing collection rather than an immutable copy. If the underlying collection mutates, those changes immediately reflect in the unmodifiable view. To create a true, isolated snapshot of your data that resists changes to the original source, use List.copyOf() introduced in Java 10.
When you pass a list to another component in your application, you usually want to guarantee its state won't change unexpectedly. You might call Collections.unmodifiableList(), hand over the reference, and assume your work is done. But there is a subtle trap in this approach that leads to unexpected side effects in production.
What is the difference between an unmodifiable view and an immutable list in Java?
An unmodifiable view prevents callers from mutating a list through that specific reference, but it remains linked to the original collection. An immutable list, by contrast, is completely decoupled from the original data source and cannot be altered by any reference.
If you pass around an unmodifiable view, you are essentially placing a clear glass shield over a whiteboard. The consumer holding the view cannot write on the glass, but if another thread or service writes directly on the whiteboard behind it, the consumer sees those changes instantly.
How does Collections.unmodifiableList handle underlying mutations?
When you pass a collection into Collections.unmodifiableList(), Java wraps your original list in a lightweight decorator. Any attempt to call write operations like add() or remove() on this wrapper throws an UnsupportedOperationException.
However, because it remains a view, any direct modification to the underlying collection updates what the view renders.
List<String> names = new ArrayList<>(List.of("Alice", "Bob"));
List<String> view = Collections.unmodifiableList(names);
names.add("Charlie"); // Modifying the underlying list
System.out.println(view.size()); // Prints 3, not 2!
If you hand this view to a service expecting a stable collection, background updates to names will leak through, potentially causing silent bugs or race conditions.
How do you create a true snapshot list in Java using List.copyOf?
Introduced in Java 10, List.copyOf() creates an unmodifiable list containing a shallow copy of the source collection's elements. Because this operation creates a brand-new backing store, subsequent modifications to the source collection have zero effect on the copied list.
It is vital to remember that List.copyOf() creates a shallow copy. While the list structure itself is completely immutable and isolated, the objects contained inside it are not cloned. If you store mutable objects inside the list, their internal properties can still be modified elsewhere.
The same concept applies across languages. If you are working in C#, calling .AsReadOnly() on a list produces a ReadOnlyCollection<T>, which behaves exactly like Java's Collections.unmodifiableList() by acting as a view over the backing list.
Comparison of Read-Only and Snapshot Collections
| Method / API | Type | Decoupled From Source? | Language Version |
|---|---|---|---|
Collections.unmodifiableList(list) |
Read-Only View | No | Java 1.2+ |
List.copyOf(list) |
Immutable Snapshot | Yes | Java 10+ |
list.AsReadOnly() |
Read-Only View | No | .NET Framework 2.0+ |
Frequently Asked Questions
Does List.copyOf create a deep copy of objects in Java?
No, List.copyOf() performs a shallow copy of the collection elements. The reference structure of the list becomes immutable and decoupled from the source collection, but the individual elements inside still refer to their original object instances in memory.
Why does Collections.unmodifiableList throw UnsupportedOperationException at runtime?
Java's collection framework uses unified interfaces like List for both mutable and read-only structures rather than separate interface hierarchies. Calling mutation methods on read-only wrappers triggers a runtime UnsupportedOperationException to enforce the contract without breaking interface consistency.
How does C# handle read-only list wrappers compared to Java?
C# uses the .AsReadOnly() extension method on List<T>, which returns a ReadOnlyCollection<T>. Just like Java's Collections.unmodifiableList(), this wrapper provides a read-only interface but remains a live view over the underlying list.
