New Collection framework?
David Holmes
david.holmes at oracle.com
Wed Feb 10 04:03:44 UTC 2016
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 other possible reason could be the Valhalla project, which tries to
> introduce value types, to enable Collections with primitive type parameters.
> There is (or was?) a discussion how to handle the remove methods on List:
> http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2015-December/000028.html
> There is a suggestion for partial methods to solve the problem, but i think
> partial methods makes the language even more complicated to compile and
> more difficult to understand.
Yes value types are increasing the strain on the API, but I have
confidence that the Valhalla folk will find acceptable ways to resolve that.
> All theese problems could be resolved by just letting the java.util Collection
> Framework as it is. And make a new one.
> I have created a proposal for it, which can be easily (modulo class names)
> used together with the java.util Collections. This is achieved by having
> wrapper Collections and converter in both directions.
> https://github.com/Blahord/BetterCollections
I have not looked at this - sorry, I simply do not have time right now.
Cheers,
David
------
> Note: This is the first release with the target to have a clean and small as
> possible API.
> Since it makes heavily use of wildcards, it is some kind of bureaucratic.
> This could be reduced, by
>
> * Adding a shortcur for wildcards like "?Type" or "? extends Type" and "!Type"
> for "? super Type" or
> * Allowing co and contra variance for type parameters.
>
More information about the core-libs-dev
mailing list