Comment #1 by jared.l.levy:
Here's a list of such collections in the library.
ConcurrentMultiset(ConcurrentMap<E,Integer>) constructor
Multimaps.newMultimap(), newListMultimap(), newSetMultimap(), newSortedSetMultimap()
ReferenceMap(ReferenceType keyReferenceType, ReferenceType valueReferenceType,
ConcurrentMap<Object,Object> backingMap) constructor
I left out cases like Comparators.givenOrder(), Multisets.unmodifiableMultiset(),
Multimaps.forMap(), Sets.union(), and the Forwarding* classes, for
which this issue's
concerns don't apply. We care about the situations when the code
sometimes uses a
user-provided backing collection and sometimes doesn't.
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
Comment #2 by kevinb9n:
Great, thanks. Bob is determined that we remove that RefMap
constructor. I also
think we can lose the ConcurrentMultiset one. I'll leave it to you to
decide what to
do for the Multimaps ones.
Comment #3 by jared.l.levy:
I'd rather keep the new*Multimap methods. since the benefits of
creating a multimap
with arbitrary backing collections are more compelling.
However, I'm fine with getting rid of the other two. The most probable
reasons for
wanting an explicit ConcurrentMap are
1) specifying the ConcurrentHashMap initialCapacity/loadFactor/concurrencyLevel
2) specifying a ConcurrentSkipListMap for a deterministic sort order
If those features are requested, we could create factory methods that
take those
parameters explicitly. Besides, a ConcurrentSkipListMap by itself
wouldn't be enough
for a sorted ReferenceMap with weak or soft references, since the ReferenceMap
implementation doesn't store the keys directly in the map.