New Collection framework?

[Thomas Kamps]

Am Mittwoch, 10. Februar 2016, 14:03:44 schrieben Sie:
> On 9/02/2016 5:29 AM, Thomas Kamps wrote:
> > Hi everyone,
> > 
> > Did you ever think about a new Collection framework for Java?
> 
> A new framework would need to be significantly better than the existing
> one to ever consider any kind of replacement. It would need to be
> compatible in such a way that users can transition over time, and that
> time would be quite lengthy - at least 2 major releases, more likely 3 IMHO.
> 
> The Java 8 Streams provide a new way for working with collections that
> can avoid problems/limitations in the base API's.
> 
> > My main complains about the java.util Collections are:
> > 
> > * No co/contra variance for assigning. Which forbids assigments like
> > List<Object> foo = new List<Number>();
> > Currently it can be bypassed when using wildcards, but then you cannot add
> > items to foo. Even more problematic are interfaces with some kind of
> > List<List<...>> as parameter
> 
> That's a language issue not a j.u.Collection issue per-se. But of course
> if generics had been around at the beginning there would likely have
> been numerous API differences in the Collection framework.
> 
> > * 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

The point of my argument was: If you dont habe modifiing methods, then you 
can't create such bugs. In many cases (at least at my work) there are Objects 
that holds some kind of Colletions, that are modified during its lifetime and 
have a getter for other to read them. If you dont want to have the inner 
collection to be modified by someone else, you can do either:

* Make a copy
* Wrap a Unmodifiable around it

The first solution can be expensive. The second one sound better, but as said, 
wrong usage will be only seen at runtime/tests. 

Yes it is true, that a distinction in ReadOnly, AddOnly, RemoveOnly and 
Mutable can cause in many classes. I have count the public Interfaces in my 
Collection-Framework: 24 in total (4 Collection, 4 Sets, 4 Maps, 4 List, 4 
ListIterators, 2 Iterable and 2 Iterator). To keep an overwiev i have put them 
into differen packages. 

I hav read the link. The main reason seems to be "Avoid Interface hell", which 
is understandable, when needing 24 Interfaces for only 3 different 
Collecction-types. but in my point of view it just feels right using the 
typesystem to avoid errors (Even it adds some kind of bureaucracy). That's 
what type systems are for: Find errors at compile time.

I also had a very brief look at Doug Lees Collection package from 1995. It has 
two Interfaces per Collectiontype (i you leave Immutablecollections out). If 
those Colelctions does not indirect removal (i.e remove at Iterator) of items, 
this would be enough.