[concurrency-interest] ConcurrentHashMapV8

Kasper Nielsen kasper at kav.dk
Mon Oct 3 12:36:59 EDT 2011

On 03-10-2011 18:04, √iktor Ҡlang wrote:
>     I really do not see practically reason for separating these into 2
>     different interfaces. Only more clutter.
> You're a firm disbeliever is the Single Responsibility Principle?

No, I am a firm believer in pragmatic design and keeping things simple.
Adding 1 interface is better then adding 2.

Look, you probably have a pretty specific use case for why you cannot 
use the equals contract when you remove an element. And you have no need 
for a custom hash code.

But I think for most other people there is no need to separate the 
responsibility of calculating a hash code and answering whether two 
object are considered equivalent. Because you need both most of the time.

One of the first things you learn when working with Java is always 
override hashCode() if you override equals(). I think it is only natural 
that any interface defining custom policies with regards to equals() or 
hashCode() supports that notion.

I mean forcing you and a handful other people to also implement 
Equivalence.hashCode() method is not going to ruin anyone's day.

>     See also
>     http://gee.cs.oswego.edu/cgi-__bin/viewcvs.cgi/jsr166/src/__extra166y/__CustomConcurrentHashMap.java
>     which supports user-defined equivalence comparisons.
> That is about the equivalence of the Keys, not of the Values.

If you look closer it also support value equivalence.


More information about the Concurrency-interest mailing list