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

[Roger Riggs]

Hi Stuart,

On 9/22/2017 4:37 PM, Stuart Marks wrote:
>
>
> 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.
What it enables, is writing a library or implementation in which the 
immutable never gets cast away.
The concrete immutable types would be the *only* types used in the 
interface to the library.
If desired a library might provide convenience functions that accept 
loosely typed lists/maps/sets
and makes copies to effect the assertions. Any objects returned would be 
the concrete immutable
types and callers could rely upon the full semantics.

I'm suggesting caution now, because if such immutable types become part 
of SE then the
new methods you are adding should be returning the concrete immutable types
and not the current interfaces with no assertions about immutability.  
Adding additional methods
with similar names later to return immutable instances will be redundant 
and create their own kind of
confusion.

Roger