SF/JavaOne, Day 3, Java 1.6 Collections

I got to go see the BirdsOfAFeather talk with Josh Bloch concerning the new collection in Java1.5 (which you can read about: here) and the upcoming collections they have planned for the future (which you can read about: here). 
I've long been a fan of the java collections and i've found that
they've normally held a good balance between simplicity and
power.  It's actually a case of "Goldilocks and the Three Bears"
for me.  stl is too complex and painful to use, .Net is too
simplistic and limited in power, whereas java get's it just about
right.  It's not perfect, but it's flexible enough to handle
almost anything you'd ever need. I always found the deep use of
abstractions to be enormously helpful for writing your own special
collections while only writing 1/10th or evern 1/100th of the code
necessary to implement the full interface.  It's also not
cluttered with a gazillion interfaces like i've seen in other packages
which isn't especially helpful in a language like java which doesn't
have unions.

However, it's starting to seem like the new collections are starting to
buckle under their own weight in recent java releases.  With the java.util.concurrent
package it seems like the number of collections grew enormously with
new axes of concurrent access and blocking access being threaded
through (no pun intended) every type of collection and interface. 
In my experience, having a collection surrounded by a reader/writer lock
usually fit the bill just fine.  Of course, i only ever had to
handle a couple of hundred threads at a time, and it's quite possible
that to be able to scale to thousands better and deeper integration of
lock-free data structures are really needed.  I also question the
need for skip lists to be introduced into the core collection
implementation methods.  I think it's important to provide core
implementations that offer linear, logarythmic and
amortized-constant/constant time performance with the associated
benefits and drawbacks.  But i don't see why skip-lists
are needed in the core collections, but i suppose the fact that Bill
Pugh is on the JSR166 expert group might have something to do with it.

However, i shouldnt' knock it until i've tried it.  I'll have to
dig up my massively overthreaded web app that i built at one point and
see if these new collections can make that code much simpler, safer,
easier to understand, and possibly faster.  If it achieves any of
those benfits without any significant drawbacks, then i guess it will
have been worth it.