50

If I write

List<Integer> a1 = Arrays.asList(1, 2, 3);
List<Integer> a2 = Collections.unmodifiableList(a1);

a2 is read-only but if I write

a1.set(0,10);

then a2 is also modified.

If in the API is said:

Returns an unmodifiable view of the specified collection. This method allows modules to provide users with "read-only" access to internal collections.

then, why if I modify the original collection also the target-copied collection is modified?

Maybe did I misunderstand the meaning and if so what's the way to write a defensive copy of that collection?

Joachim Sauer
  • 302,674
  • 57
  • 556
  • 614
xdevel2000
  • 20,780
  • 41
  • 129
  • 196
  • 1
    If you wanted to have an unmodifiable version of a1 then you could clone a1 and make that an unmodifiable list. Then updates to a1 would not effect a2. – Steve W Jan 06 '17 at 10:44

9 Answers9

55

Yes, you understood it correctly. The idea is that the object returned by umodifiableCollection can't directly be changed, but could change through other means (effectively by changing the internal collection directly).

As long as something has access to the internal list, the "unmodifiable" collection could be changed.

That's why you usually construct a unmodifiable collection and make sure that nothing can ever get to the internal list:

Collection<Integer> myUmodifiableCollection = Collection.umodifiableCollection(Arrays.asList(1, 2, 3));

Since nothing ever gets a reference to the List created by asList, this is a truly unmodifiable collection.

The advantage of this approach is that you don't need to copy the original collection/list at all, which avoids using memory and computing power.

Guava provides the ImmutableCollection class (and its subclasses such as ImmutableList) which provide true immutable collections (usually by copying the source).

zeugor
  • 822
  • 1
  • 8
  • 18
Joachim Sauer
  • 302,674
  • 57
  • 556
  • 614
  • `Arrays.asList()` already returns a fixed size List. So why do we need to additionally decorate it using `Collections.unmodifiableList()`?I see both you and @assylias have used the same idiom. Can you please explain? – Geek Jul 06 '14 at 11:41
  • 8
    @Geek: While `Arras.asList()` returns a fixed size List, it does not return an unmodifiable one. You can still change elements by using `set(int,T)`. `Collections.unmodifiableList()` "fixes" that by disallowing this. But in any real-world code I'd probably just use the Guava `ImmutableList` (linked to above), as it is shorter to write, very clear and always make sure that nothing can "leak". – Joachim Sauer Jul 06 '14 at 22:20
12

Maybe did I misunderstand the meaning and if so what's the way to write a defensive copy of that collection?

Typically, you would use it that way:

private List<Integer> a1 = Arrays.asList(1, 2, 3);

public List<Integer> getUnmodifiable() {
    return Collections.unmodifiableList(a1);
}

Someone who calls getUnmodifiable and does not have access to the internal of your class (i.e. they can't acces the private variable a1), won't be able to modify the returned list.

assylias
  • 321,522
  • 82
  • 660
  • 783
  • 1
    `Arrays.asList()` already returns a fixed size List. So why do we need to additionally decorate it using `Collections.unmodifiableList()`? What am I missing? – Geek Jul 06 '14 at 11:36
  • 4
    You can't add to a1 but you can set any item to something different. – assylias Jul 06 '14 at 19:30
  • 1
    @assylias Actually you could modify the internal of objects in the list, but you can't use set() method to replace a old object with another one in the list. – Sam003 Jul 23 '15 at 04:21
4

If you were looking to keep a1 mutable and make an immutable copy of it without Guava, this is one way you could do it.

    List<Integer> a1 = Arrays.asList(1, 2, 3);
    List<Integer> a2 = Collections.unmodifiableList(new ArrayList<>(a1));
Travis Miller
  • 449
  • 4
  • 4
2

Since Java 10 you may do List.copyOf():

List<Integer> a1 = Arrays.asList(1, 2, 3);
List<Integer> a2 = List.copyOf(a1);

After that, changes to a1 are not visible through a2, because List.copyOf() copies the contents of your list to a new one. The copy is unmodifiable. But make sure to read the documentation on the method before using it, because it does not work with lists containing null values.

Ilya Posov
  • 138
  • 3
  • 9
1

The idea is that you can't modify the list via a2.

Modifying the a1 list will indeed modify what you see in a2 - this is intended.

Just dont have a public way to access the list a1, and you should have what you want :)

vikingsteve
  • 38,481
  • 23
  • 112
  • 156
1

the API says it internal collections in your case the collection is not internal

the point is that when you have a private list in class an a gettet for that list, then you may want callers of the getter to not be able to modify the list in witch case you'll have to return an umodifiable list. otherwise the returned list is just a reference to your internal/private list and thus its content can be modified.

A4L
  • 17,353
  • 6
  • 49
  • 70
1

The statement:

Collections.unmodifiableList(a1);

returns a wrapper over the original collection whose modifier methods throw UnsupportedOperationException.

The wrapper is read-through, meaning that if you modify a1, the changes reflect on the wrapped collection a2.

Carlo Pellegrini
  • 5,656
  • 40
  • 45
  • 1
    Actually you could modify the internal of objects in the list, but you can't use set() method to replace a old object with another one. – Sam003 Jul 23 '15 at 04:20
0

a1 and a2 will reference the same data (memory).

the un-mofifiable part comes , only with a2 as entry.

imaging if you are passing a2 to a method where you expect the method to be idempotent. such cases a2 helps.

in summary you cant modify data using a2 pointer.

TheWhiteRabbit
  • 15,480
  • 4
  • 33
  • 57
0

If you need unmodifiable and immutable list or in other words unmodifiable copy of the source list without any dependency to other libraries try this:

Collections.unmodifiableList(Collections.list(Collections.enumeration(sourceList)))

Collections.list() copies values from its enumeration.

Radio Rogal
  • 462
  • 4
  • 9