[concurrency-interest] ConcurrentReferenceMap enhancement to 166 - Feedback Requested

Jason T. Greene jason.greene at redhat.com
Wed Apr 16 17:39:13 EDT 2008


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


More information about the Concurrency-interest mailing list