Are ANY additions/improvements to the collections API considered for JDK7?
assembling.signals at yandex.ru
Thu Nov 25 20:58:32 UTC 2010
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? ;)
Ivan G Shevchenko
More information about the core-libs-dev