I was running into problems with different teams at my employer using different Immutable Collection implementations and wanted to avoid writing code to adapt each Collection

[Stuart Marks]

As Remi pointed out, retrofitting the interfaces this way would imply that ArrayList 
implements UnmodifiableCollection. (This seems semantically wrong in the first 
place, but it might be mitigated by renaming things to ReadableCollection etc.)

Another point is that UnmodifiableCollection isn't a Collection, so adding its 
elements to an existing collection via myArrayList.addAll(unmodcoll) would no longer 
work without some additional adaptation.

Additionally, UnmodifiableCollection would implement UnmodifiableIterable but not 
Iterable, so it would no longer be possible to iterate using a for-loop. Again, not 
without additional adaptation.

I've written some about this issue here:

     https://stackoverflow.com/a/57926310/1441122

One alternative this SO answer doesn't cover is having no type relationship between 
UnmodifiableCollection and Collection, similar to the way Eclipse Collections does 
it. That's another stable point in the design space, and it has a bunch of different 
tradeoffs. It also requires the addition of a bunch of adapters between the hierarchies.

A central decision is whether "unmodifiable" allows unmodifiability to be cast away, 
whether it permits modification only via another reference (an "unmodifiable view"), 
or whether it indicates the underlying collection itself is unmodifiable ("shallowly 
immutable"). Closely related is the issue of what to do about the return type of 
methods like List.of() and Collections.unmodifiableList() and related methods.

Remi noted previously that the idea of unmodifiable collection interfaces was 
rejected from the initial design. That doesn't mean it's a bad idea and that they 
can never be added. Indeed, proposals and questions in this area do come up from 
time to time. The problem is that doing this (for whatever definition of "this") is 
harder than it seems at first glance, and the benefits provided have never been 
quite able to justify the additional complexity this would add to the platform.

s'marks



On 1/31/21 2:10 PM, Larry Diamond wrote:
> Wow thanks for getting back to me so quickly.   I'll read over the existing
> conversation.   Thank you very much
> 
> On Sun, Jan 31, 2021 at 4:19 PM Remi Forax <forax at univ-mlv.fr> wrote:
> 
>> Hi Larry,
>> this design was considered and rejected when the collection API vas
>> introduced in JDK 1.2
>> see
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/066245.html
>>
>> Furthermore, if List extends ImmutableList, it means that ArrayList
>> implements ImmutableList which is just plain wrong.
>> Consider the following code
>>    record Foo(ImmutableList<String> list) { }
>>    var arrayList = new ArrayList<String>();
>>    var foo = new Foo(arrayList);
>>    System.out.println(foo.list()); // []
>>    arrayList.add("oops");
>>    System.out.println(foo.list()); // [oops]
>>
>> regards,
>> Rémi
>>
>> ----- Mail original -----
>>> De: "Larry Diamond" <ldiamond at ldiamond.com>
>>> À: "jdk-dev" <jdk-dev at openjdk.java.net>
>>> Envoyé: Dimanche 31 Janvier 2021 21:28:33
>>> Objet: I was running into problems with different teams at my employer
>> using different Immutable Collection
>>> implementations and wanted to avoid writing code to adapt each Collection
>>
>>> I was thinking of submitting a proposal for UnmodifiableCollections for
>>> Java.
>>>
>>> I wrote up a first draft of a JEP for this.
>>>
>>> What do you think?
>>>
>>> Thank you very much
>>> Larry Diamond
>>