See the JavaDocs and this talk by Stuart Marks (or previous versions of it).
I'll be using the following for the code examples:
List<Integer> listOf = List.of(...);
List<Integer> asList = Arrays.asList(...);
List<Integer> unmodif = Collections.unmodifiableList(asList);
Structural immutability (Or: unmodifiability)
Any attempt to structurally change List.of
will result in an UnsupportedOperationException
. That includes operations such as add, set and remove. You can, however, change the contents of the objects in the list (if the objects are not immutable), so the list is not "completely immutable".
This is the same fate for unmodifiable lists created with Collections.unmodifiableList
. Only this list is a view of the original list, so it can change if you change the original list.
Arrays.asList
is not completely immutable, it does not have a restriction on set
.
listOf.set(1, "a"); // UnsupportedOperationException
unmodif.set(1, "a"); // UnsupportedOperationException
asList.set(1, "a"); // modified unmodif! unmodif is not truly unmodifiable
Similarly, changing the backing array (if you hold it) will change the list.
Structural immutability comes with many side-effects related to defensive coding, concurrency and security which are beyond the scope of this answer.
Null hostility
List.of
and any collection since Java 1.5 do not allow null
as an element. Attempting to pass null
as an element or even a lookup will result in a NullPointerException
.
Since Arrays.asList
is a collection from 1.2 (the Collections Framework), it allows null
s.
listOf.contains(null); // NullPointerException
unmodif.contains(null); // allowed
asList.contains(null); // allowed
Serialized form
Since List.of
has been introduced in Java 9 and the lists created by this method have their own (binary) serialized form, they cannot be deserialized on earlier JDK versions (no binary compatibility). However, you can de/serialize with JSON, for example.
Identity
Arrays.asList
internally calls new ArrayList
, which guarantees reference inequality.
List.of
depends on internal implementation. The instances returned can have reference equality, but since this is not guaranteed you can not rely on it.
asList1 == asList2; // false
listOf1 == listOf2; // true or false
Worth mentioning that lists are equal (via List.equals
) if they contain the same elements in the same order, regardless of how they were created or what operations they support.
asList.equals(listOf); // true i.f.f. same elements in same order
Implementation (warning: details can change over versions)
If the number of elements in the list of List.of
is 2 or less, the elements are stored in fields of a specialized (internal) class. An example is the list that stores 2 elements (partial source):
static final class List2<E> extends AbstractImmutableList<E> {
private final E e0;
private final E e1;
List2(E e0, E e1) {
this.e0 = Objects.requireNonNull(e0);
this.e1 = Objects.requireNonNull(e1);
}
}
Otherwise they are stored in an array in a similar fashion to Arrays.asList
.
Time and Space efficiency
The List.of
implementations which are field-based (size<2) perform slightly faster on some operations. As examples, size()
can return a constant without fetching the array length, and contains(E e)
does not require iteration overhead.
Constructing an unmodifiable list via List.of
is also faster. Compare the above constructor with 2 reference assignments (and even the one for arbitrary amount of elements) to
Collections.unmodifiableList(Arrays.asList(...));
which creates 2 lists plus other overhead. In terms of space, you save the UnmodifiableList
wrapper plus some pennies. Ultimately, the savings in the HashSet
equivalent are more convincing.
Conclusion time: use List.of
when you want a list that doesn't change and Arrays.asList
when you want a list that can change (as shown above).