16

If you have a List<String> strings instance, would you keep writing:

Collections.unmodifiableList(strings)

or switch to:

List.of(strings.toArray(new String[strings.size()]))

What's the initial impact in performance (memory- and runtime-wise) of instantion? Is there a runtime benefit in the List.of variant?

Sormuras
  • 7,555
  • 1
  • 34
  • 63
  • The runtime benefit is with `unmodifiableList` on creation. And if `strings` is an `ArrayList` there is no reason for `List.of`. – Joop Eggen Sep 08 '16 at 08:29
  • Possible duplicate of [What is the difference between List.of and Arrays.asList?](https://stackoverflow.com/questions/46579074/what-is-the-difference-between-list-of-and-arrays-aslist) – Mark Oct 06 '17 at 15:16

2 Answers2

18

This is not really a good comparison because these approaches do different things:

  • Collections::unmodifiable... creates an unmodifiable view. It is not immutable because it changes if you're changing the original, backing collection (list in your example).
  • ...::of on the other hand, creates an immutable copy. Changing the original list will not affect it.

From a performance view it is obvious that creation of the unmodifiable wrapper is cheaper because it only creates one instance with a single field. The new factory methods will create at least one object, maybe backed by an array (if you have three or more elements), that it needs to copy into.

Access could be faster on the new immutable collections but that would have to be benchmarked.

But correctness trumps performance. What do you need? If you need an immutable copy, use the new methods (or Guava's Immutable..., which I would prefer). If you need something immutable, use unmodifiable... and throw away the original (and make sure it stays like that). If you need a view that your caller can not edit, use unmodifiable....

Nicolai Parlog
  • 42,869
  • 22
  • 115
  • 245
5

According to JEP 269 (Convenience Factory Methods for Collections):

Goals

Provide static factory methods on the collection interfaces that will create compact, unmodifiable collection instances. The API is deliberately kept minimal.

Non-Goals

  • It is not a goal to provide a fully-general "collection builder" facility that, for example, lets the user control the collection implementation or various characteristics such as mutability, expected size, loading factor, concurrency level, and so forth.

  • It is not a goal to support high-performance, scalable collections with arbitrary numbers of elements. The focus is on small collections.

  • It is not a goal to provide unmodifiable collection types. That is, this proposal does not expose the characteristic of unmodifiability in the type system, even though the proposed implementations are actually unmodifiable.

  • It is not a goal to provide "immutable persistent" or "functional" collections.

Andrew Tobilko
  • 46,063
  • 13
  • 87
  • 137
  • 1
    Add a synopsis of what you want to express: your point is not entirely clear, though I can guess. – Joop Eggen Sep 08 '16 at 08:40
  • Are `Collections.unmodifiableXyz` methods build for high-performance? Maybe a JMH test will show the difference. My use-case copes 99% with small lists. That would go conform with the goal of JEP 269. – Sormuras Sep 08 '16 at 08:46