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

assembling signals assembling.signals at
Thu Nov 25 20:58:32 UTC 2010

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.

* 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

More information about the core-libs-dev mailing list