Are ANY additions/improvements to the collections API considered for JDK7?

[David Holmes]

Skipping to the final questions :)

assembling signals said the following on 11/26/10 06:58:
 > With that in mind, will be any additions/improvements to the
 > collections API considered for JDK7?

There are already a number of additions and changes for collections in 
the OpenJDK 7 codebase. Most of these are in the concurrent collections 
area - and there are not a huge number of them. More are likely for JDK 
8 due to the proposed integration of closures (see JSR-335 
http://www.jcp.org/en/jsr/detail?id=335 )

The ongoing philosophy with Collections has been that every API change 
has to "carry its own weight":

http://download.oracle.com/javase/6/docs/technotes/guides/collections/overview.html

"The main design goal was to produce an API that was reasonably small, 
both in size, and, more importantly, in "conceptual weight." "

 > I want to remind everyone that there is a great psychological
 > difference between
 > a) having an ecosystem which doesn't provide lot functionality, BUT
 > can be extended easily (by using external APIs or writing own
 > mini-solutions);
 > b) having an ecosystem which offers most frequently used functionality
 > out-of-the-box.

If every suggestion for a new collection API were implemented in the JDK 
it would be a very bloated and difficult to maintain set of classes. It 
would also be harder to use effectively as people would struggle to 
understand exactly which "tool" was right for their job. Different 
people have different needs and requests for things have to reach 
"critical mass" to be accepted in general - for example a lot of the 
concurrent collections work comes from the discussion on Doug Lea's 
concurrency-interest mailing list.

While it is nice in theory to have every possible tool in the toolbox 
just in case, you don't want the toolbox to be so large as to need a 
semi-trailer to lug it around, and a GPS locator to find things in it. 
Nor so complex that you can't work out which tool is best for the job at 
hand.

 > Will this mail be ignored? ;)

Time will tell :)

Cheers,
David Holmes
------------

assembling signals said the following on 11/26/10 06:58:
> Hello community!
> 
> I read several times (in mailing lists, forums, blogs, ...) about several small requests
> (proposed over and over again) for specific ideas for the collections API.
> 
> Examples:
> * adding certain new collection classes / interfaces
>   (such as some multi-key-maps, multi-equal-value-sets, multi-you-name-it-what, ... );
> * adding more functions to utility classes;
> * merging parts from certain advanced collections APIs,
>   even the possibility of merging parts from Google Collections API (or how is it called)
>   were considered (however I don't remember, whether those were official statements).
> 
> Most requests are either ignored or rejected with comments, such as:
> * "use this and that external API";
> * "use this and that little workaround, it's not that complex";
> * "this it too specific to be included";
> * [request or comment ignored] (as happens often on mailing lists)
> 
> I want to remind everyone that there is a great psychological difference between
> a) having an ecosystem which doesn't provide lot functionality, BUT can be extended easily
>   (by using external APIs or writing own mini-solutions);
> b) having an ecosystem which offers most frequently used functionality out-of-the-box.
> 
> Option b) is more complex on the development and maintainability side, but much more
> welcomed by end users. Examples:
> * a webbrowser is considered to be better when it doesn't have to be extended using 100 addons
>   to be usable (see: Firefox's ability to print to PDF, read news feeds, ...)
> * an IDE is considered to be better when it offers (let's say) version control for common versioning
>   systems (such as Netbeans DOES and Eclipse DOESN'T)
> 
> With that in mind, will be any additions/improvements to the collections API considered for JDK7?
> Will this mail be ignored? ;)
> 
> Best regards,
> Ivan G Shevchenko