Thanks for the feedback, but IIUIC any implementation of the standard interfaces will have threading issues, the very least synchronization overheads. But I'll take an in-depth look at the 1.5 concurrent collections tomorrow.
Immutability seems to be so much smarter choice. -- Niclas On Oct 12, 2009 7:21 PM, "Stuart McCulloch" <[email protected]> wrote: 2009/10/12 Niclas Hedhman <[email protected]> > > Gang, > > I have long (>10years) been annoyed over the mutability of the JDK > collection classe... as Paul pointed out the JDK concurrent collection classes do something similar (they also use internal partitioning to reduce update contention) > I am also growing fond of the Visitor pattern, > as we have used extensively in Qi4j (also avoids ... you might want to take a look at the Google Collections "MapMaker": http://google-collections.googlecode.com/svn/trunk/javadoc/index.html?com/google/common/collect/MapMaker.html which can build all sorts of maps (inc. reference and computed maps) for completeness I should also point out another JSR166y candidate: http://anonsvn.jboss.org/repos/jbosscache/experimental/jsr166/src/jsr166y/ConcurrentReferenceHashMap.java which provides an alternative concurrent reference map to the Google implementation (which relies on a background thread to evict entries) > > > So, some measurements for the HashMap implementation can > be found > below... > The testcase is ... > > > _______________________________________________ > general mailing list > > [email protected] >... > -- Cheers, Stuart _______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
_______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
