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

[Galder Zamarreño]

On Mar 21, 2013, at 3:10 PM, Dan Berindei <dan.berindei at gmail.com> wrote:

> 
> 
> 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

^ Well spotted!! I hadn't seen it :)

It goes a little beyond with strong/weak map selection which is not important for us in the internal container right now (it could be if some crazy person decided to cache things crazy stuff like classloaders in Infinispan :O…)

It's interesting what he's done with Equivalence interface (better name than Comparing TBH), but can't see how he can make equals() typed on one of the elements… I need to revise my implementation to see if that's possible…

Dan, excellent feedback! As always :))

> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Galder Zamarreño
galder at redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org