[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?)

Dhanji.

On Thu, Apr 17, 2008 at 7:39 AM, Jason T. Greene <jason.greene at redhat.com>
wrote:

> Jason Mehrens wrote:
> > Jason
> >
> > Here is my $0.02.
>
> Thanks for the feedback!
>
> >  > 1) Should the IDENTITY_COMPARISONS option apply to values and keys,
> or
> >  > 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
> merged
> >  > 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
> (WEAK_KEYS
> >  > + SOFT_KEYS).
> >
> > Probably should keep key type and value type as separate parameters.
>
> Ok.
>
> > 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
> the
> >  > 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
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20080417/1fcecedd/attachment-0001.html 


More information about the Concurrency-interest mailing list