New Collection framework?

[Stanislav Baiduzhyi]

On 10/02/16 05:03, David Holmes wrote:
>> * The main Collection interface allowes too much. If you get a
>> Collection and
>> you should not modify it, your programm will either behave stragly
>> with a hard
>> to detect bug, or crash with some kind of
>> UnsupportedOperationException, when
>> you do it.
>> I have my problems with UnsupprtedOperationException, because when i
>> get a
>> Collection, i have to read the documentation (if existing) to know
>> what i am
>> allowed to do, or run unexpectedly into an exception. Would it be
>> great to
>> hava an "readonly" interface, which simply does not have and modifing
>> methods?
>
> I don't understand your problem. If you write a method that takes a
> collection then your method has a specification as to what it does that
> involves the collection that is passed in. If the passed in collection
> doesn't in fact support that then the UnsupportedOperationException
> propagates back to the caller that passed you an inappropriate
> collection - and that's exactly as it should be. If you take a
> collection and then try to do something to it that you didn't specify
> you were going to do, and get UnsupportedOperationException then that is
> a bug in your code - if you let it propagate then your caller gets it
> and the user of your code submits a bug report.
>
> In case you have not seen it there is a document that discusses the
> design of the Collections framework and why the existing approach was
> taken:
>
> https://docs.oracle.com/javase/8/docs/technotes/guides/collections/designfaq.html

No that's little different. I've had similar issues on multiple 
projects. When you want to keep your DTOs immutable, you have to either 
return a copy of collection in getter or wrap it into unmodifiable. 
Unmodifiable is not visible on API level but behaves differently on 
implementation level, making it harder to support. So many projects are 
just returning Guava ImmutableList or similar, to make it obvious on API 
level that this collection should not be modified.

So yes, you are correct that it is documented and not an issue of JDK. 
Yet it is a valid issue of API design, having something like 
ImmutableList on API level would make it much simpler to follow 
self-documenting code principles and would improve maintenance cost in 
general.

It would be very helpful to have a Collection extending some kind of 
ReadOnlyCollection (and similar to List and Set) that has only read 
operations, but probably that is not doable in backward-compatible manner.

-- 
Regards,
     Stas