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

Reply via email to