HashCodeCacheKeyGenerator provides bad keys for float and double method parameters

[GoogleCodeExporter]

What steps will reproduce the problem?
1. mark a method with float or double parameters as Cacheable using the default 
key generator
2. access the method twice with different parameters differing only in the 
non-integer part
3. see the cache get hit on the second time rather than passing through to the 
method

Noticed in ehcache-spring-annotations 1.0.3

Suggested fix: HashCodeCacheKeyGenerator#getHashCode(Number) should use 
hashCode() in 
rather than longValue() -- in fact, why not just remove the method and allow 
the 
getHashCode(Object) to work?

Original issue reported on code.google.com by adam.coh...@gmail.com on 27 May 2010 at 10:33

[GoogleCodeExporter]

Do you have two example values I can use to create a unit test to verify the 
issue
and make sure it doesn't come up again?

Original comment by eric.dalquist on 27 May 2010 at 1:10

[GoogleCodeExporter]

I've committed a fix. Now the only special number handling that exists is for 
Double
and Long. Long values are used directly and Double values are used via
doubleToLongBits which ensures that all of the bits of the Double are correctly 
used
in the hash.

A test case would still be appreciated.

Original comment by eric.dalquist on 28 May 2010 at 9:52

• Changed state: Fixed
• Added labels: Milestone-Release1.0.5

[GoogleCodeExporter]

Thanks for the fix!

Here's a simple test case.

Thanks,

Adam

Original comment by adam.coh...@gmail.com on 21 Jun 2010 at 9:09

Attachments:

• HashCodeCacheKeyGeneratorFloatTest.java

[GoogleCodeExporter]

Thanks for the patch. I'll add those tests to both the 1.0 and 1.1 branches to 
make sure we don't have a regression here.

Original comment by eric.dalquist on 21 Jun 2010 at 4:00