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

[Stuart Marks]

On 9/22/17 5:36 AM, Roger Riggs wrote:
> Hi Stuart,
>
> I'm cautious about doing work piecemeal toward immutable collections.
> The current unmodifiable approach only gives partial protection to the caller
> and none to the callee. The assertions it makes are too weak to be useful.

I'm not entirely sure what you're driving at here. Looking at this again, I can 
see at least one place that should be strengthened. In List.copyOf, something 
like this should be added:

     Any modifications to the given Collection are not reflected in the
     returned List.

(And similar for Set.copyOf and Map.copyOf.)

Are there other assertions that should be added or strengthened?

> 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.

> BTW, I don't think many people are confused by 'immutable' collections appearing
> to be mutated because one of the objects in the collection is mutable.

I'm sure *you* aren't confused by the issues. But I spend a lot of effort 
explaining these issues to the general public, so I think the change is worthwhile.

s'marks

> Thanks, Roger
>
>
> On 9/21/2017 2:55 PM, Stuart Marks wrote:
>>
>>
>> On 9/21/17 5:42 AM, Alan Bateman wrote:
>>> On 21/09/2017 01:02, Stuart Marks wrote:
>>>> http://cr.openjdk.java.net/~smarks/reviews/8177290/webrev.0/
>>> I read through the updated/new definitions and they read well.
>>
>> Great.
>>
>>> For the copyOf methods then I can't immediately tell from the javadoc if the
>>> given collection can contain null elements. Taking List.copyOf as an example
>>> where coll may be null or it may contain null elements. The javadoc does link to
>>> "Unmodifiable lists" where it specifies the characteristics of the lists
>>> returned by the static factory methods - these include disallowing null
>>> elements. So I think this needs to be clarified.
>>
>> Agreed, I'll work on some clarifications here, and also disallow null for the
>> argument itself.
>>
>>> Minimal implementation is okay to get started but what is the reason not to
>>> include some basic tests?
>>
>> Sorry, I should have been more clear about this. The changeset is clearly not
>> ready to go in as it stands. I wanted to get an initial review of the
>> specifications going, then file a CSR request, etc. while continuing to work
>> on tests and better implementations. I'll post a subsequent review when
>> they're ready.
>>
>> Thanks.
>>
>> s'marks
>>
>