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

On Thu, Mar 21, 2013 at 1:17 PM, Galder Zamarreño <galder(a)redhat.com&gt; wrote: On Mar 20, 2013, at 11:52 AM, Manik Surtani <msurtani(a)redhat.com&gt; wrote: > > On 18 Mar 2013, at 12:21, Galder Zamarreño <galder(a)redhat.com&gt; 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/351e29d327d163ca8e941edf8... > > 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/CustomCon...

_______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev