[infinispan-dev] Bye bye wrappers, ComparingConcurrentHashMapv8 is here (ISPN-2281)

[Dan Berindei]

On Thu, Mar 21, 2013 at 1:17 PM, Galder Zamarreño <galder at redhat.com> wrote:

>
> On Mar 20, 2013, at 11:52 AM, Manik Surtani <msurtani at redhat.com> wrote:
>
> >
> > On 18 Mar 2013, at 12:21, Galder Zamarreño <galder at redhat.com> wrote:
> >
> >> This is why, I've created a new CHM, based on the CHMv8, called
> ComparingConcurrentHashMapv8 (thx Tristan for the name!). The work for this
> can be seen in:
> https://github.com/galderz/infinispan/commit/351e29d327d163ca8e941edf873f6d46b43cfae1
> >
> > Sounds good, but why not extend
> org.infinispan.util.concurrent.jdk8backported.ConcurrentHashMapV8?
>
> To be honest, I'm considering keeping only one ConcurrentHashMapV8 around,
> which had the Comparing functions pluggable…, and I might end up doing
> that. IOW, a ComparingConcurrentHashMapV8 instance created with
> ComparingObject function for both keys and values is functionality
> equivalent ConcurrentHashMapV8 with little/hardly impact.
>
> I originally wanted to keep two versions so that I could more easily port
> over changes in JSR-166 to
> org.infinispan.util.concurrent.jdk8backported.ConcurrentHashMapV8, and then
> pass this on to ComparingCHMv8… but I don't think it's worth it.
>
>
Interesting, the extra166y package had a CustomConcurrentHashMap [1] that
did exactly what you want, but Doug Lea didn't port it over to
ConcurrentHashMapV8. Guava too has a CustomConcurrentHashMap class, but
it's also based on the old ConcurrentHashMap code.

I think maintaining one ConcurrentHashMapV8 class is hard enough, and I
doubt there would be any performance difference between the two versions.
So I vote to keep only the Comparing version.

[1]
http://gee.cs.oswego.edu/dl/jsr166/dist/extra166ydocs/extra166y/CustomConcurrentHashMap.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20130321/d66bae7f/attachment.html