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

[forax at univ-mlv.fr]

OK !
you convince me.

Rémi

----- Mail original -----
> De: "Stuart Marks" <stuart.marks at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoyé: Mercredi 29 Novembre 2017 06:21:41
> Objet: Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

> On 11/22/17 8:45 AM, Remi Forax wrote:
>> I think i prefer toImmutableList() than toUnmodifiableList() because the List
>> is truly immutable and not an unmodifiable proxy in front of a mutable List
>> (like Collections.unmodifiableList() does).
> 
> Immutability is like wine.
> 
> If you put a spoonful of wine in a barrel full of sewage, you get sewage. If you
> put a spoonful of sewage in a barrel full of wine, you get sewage.
> (Schopenhauer's Law of Entropy)
> 
> Similarly, if you add a little immutability to something mutable, you get
> mutability. And if you add a little mutability to something immutable, you get
> mutability.
> 
> To get the desired properties of immutability (e.g., thread-safety, or the
> ability to hand around references safely without making defensive copies), it's
> insufficient for a collection to be "immutable"; you also have to make some
> statements about the contents. It's thus more precise to say that a collection
> is unmodifiable, and to provide a clear definition of an unmodifiable
> collection.
> 
> Although unmodifiable collections have been around since the collections
> framework was introduced, oddly enough the concept has never had a good
> definition. The current proposal includes definitions for unmodifiability,
> unmodifiable collections, and unmodifiable views, and it clearly specifies which
> APIs return unmodifiable views and which return unmodifiable collections.
> 
> s'marks