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

Stephen Colebourne scolebourne at joda.org
Mon Sep 25 10:36:20 UTC 2017

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

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

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


More information about the core-libs-dev mailing list