OK ! you convince me. Rémi ----- Mail original -----
De: "Stuart Marks" <stuart.marks@oracle.com> À: "Remi Forax" <forax@univ-mlv.fr> Cc: "core-libs-dev" <core-libs-dev@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