[concurrency-interest] ConcurrentReferenceMap enhancement to 166 - Feedback Requested
Dhanji R. Prasanna
dhanji at gmail.com
Thu Apr 17 02:40:04 EDT 2008
Hi Jason (Greene)
This is cool =)
I also prefer the enum as it is a tight contract.
Btw, doesn't google-collections have a similar utility? I notice that it
uses a composition pattern with CHM, and that your version does not. Can I
ask about the motivation for this? (I presume, without due research, that a
similar lock-striping strategy to CHM is in use?)
On Thu, Apr 17, 2008 at 7:39 AM, Jason T. Greene <jason.greene at redhat.com>
> Jason Mehrens wrote:
> > Jason
> > Here is my $0.02.
> Thanks for the feedback!
> > > 1) Should the IDENTITY_COMPARISONS option apply to values and keys,
> > > just to keys as it does now? If not, should there be separate options
> > > for both?
> > It has reference in the name so I would only allow identity comparisons.
> There are a number of good use cases that need standard equality. A
> couple of examples are:
> - Soft cache using keys that potentially come from serialization
> - An intern pool. (e.g. String.intern())
> Also, the general contract of Map requires standard equality
> (technically identity maps violate this contract). So IMO we should
> continue to support this behavior.
> > >
> > > 2) Should the key reference type, and the value reference type be
> > > into the option enum, instead of providing separate parameters? This
> > > reduces the number of overloaded constructors, but introduces the
> > > problem of having a combination of mutually exclusive options
> > > + SOFT_KEYS).
> > Probably should keep key type and value type as separate parameters.
> > Why not use the class type of the references.
> > I.E. ReferenceMap.newMap(WeakReference.class, Reference.class) //weak
> > keys, strong values.
> > Maybe that is too much of an enum anti-pattern.
> Clever/interesting idea. Although, I still think an enum is better
> because you immediately know all possible values, and you have nice
> static type checking.
> > >
> > > 3) Should the configuration values be exposed via get methods so that
> > > calling code can introspect the map configuration? Currently none of
> > > standard collections allow you to do this (load factor, etc).
> > >
> > No.
> Ok, Thanks again.
> Jason T. Greene
> JBoss, a division of Red Hat
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest