RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

[Stephen Colebourne]

On 22 September 2017 at 21:37, Stuart Marks <stuart.marks at oracle.com> wrote:
> On 9/22/17 5:36 AM, Roger Riggs wrote:
>> I think more value can be achieved by creating concrete final immutable
>> collections
>> that applications can use to be certain that the semantics of the
>> collection
>> are immutable. They can implement the current interfaces but would be
>> compile time
>> knowable of the complete semantics of mutability.  Then a good bridge
>> between
>> the current streams (and collections) would be methods that return the
>> concrete
>> final collections.
>
> It would add some value to have concrete, "immutable" collection classes
> exposed. Presumably though these would implement the List/Set/Map
> interfaces. As instances get passed around, the "immutable" part would get
> "cast" away, limiting the value added.
>
> There is a large design space here (see Guava and Eclipse Collections, among
> others that have this concept of "immutability). They're certainly
> interesting, but I haven't yet seen an approach that is clearly better than
> the current approach of keeping the implementation classes completely
> hidden.

Like Roger, I am cautious about this design space. We use Guava's
Immutable* collection classes everywhere because we want to clearly
assert the immutable nature. But it is a risk, because Guava does
change its API more than most, and we are limited to the concrete
classes that they provide. There is no ImmutableList.nCopies() for
example.

What we really need however is immutability as a language feature,
where an immutable collection can be an interface, and it can assert
that only other immutable classes can be contained. Since we are a
long way from this, it seems reasonable to make the change outlined in
the webrev. It also seems reasonable to use the term "unmodifiable"
not "immutable" to leave "immutable free for the future.

I think it is unfortunate that we have List.of(E...), as it would have
been better to have List.copyOf(E[]) alongside
List.copyOf(Collection).

While I know Iterable is out of fashion, it would be an appropriate
choice here to make the method as widely applicable as possible.

Stephen