• Bug
  • Status: Resolved
  • 2 Major
  • Resolution: Won't Fix
  • teck
  • Reporter: sergiob
  • September 06, 2010
  • 0
  • Watchers: 3
  • September 06, 2013
  • September 06, 2013

Description

The com.terracotta.toolkit.collections.chm.SelectableConcurrentHashMap doesn’t work when arrays (more specifically in my case, a byte array) are used as keys, because the hash code calculation used for arrays (the default one) resorts to using the memory address, making logically equal arrays different. Arrays.hashcode should be used instead if the passed key is an array.

Comments

Tim Eck 2010-09-07

I don’t know what that class (SelectableConcurrentHashMap) is to be honest, I’ll have to defer to others to decide if it should be changed.

That said I have a comment and a question. The comment is that any classes (public or not) in the com.terracotta.* package space are not part of the official toolkit API. We don’t make any guarentees about those types in terms of compatibility from release to the next (much like sun.* classes in the JDK).

The question is whether you know of a map implementation that special cases arrays like this for hashing purposes. It feels a little off to do something like that. I understand you can’t just create an array with the same elements and use it as the key. Seems like you’d be better of with a wrapper object perhaps where you can control equals/hashcode.

Sergio Bossa 2010-09-07

Thanks for your answer Tim.

In regard to your last comment/question, I’d be more than happy to use a wrapper type as a key for a ClusteredMap … if only the toolkit supported custom types :) But, the toolkit only supports primitive types and I was trying to use a byte[] because String (the actual workaround for this problems) has much larger memory occupation.

Any suggestions?

Sergio Bossa 2010-09-07

Moreover, I should add that: 1) I talked about the hashcode method, but equals doesn’t work for arrays either. 2) The problem is in both SelectableConcurrentHashMap and the repackaged ConcurrentHashMap.

Tim Eck 2010-09-07

I think you hit the nail on the head about supporting custom types in the express data structures. That seems like the “right” way to get this use case working, not that the solution to that general issue is in the works unfortunately.

Fiona OShea 2012-10-01

Not part of TOokit Project

Tim Eck 2012-10-23

moving this out for now. The new collections in toolkit2 support serialization intrinsically so you can (more or less) use your own types as keys. The caveat is CDV-1446