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
