What methods should go into a java.util.Objects class in JDK 7?
Martin Buchholz
martinrb at google.com
Thu Sep 10 02:28:15 UTC 2009
I've updated the hashCode patch to include Booleans
and similar refactoring as in compare.
We could do worse than to do hashCode in a totally
analogous fashion to compare, but I could also see
them incorporated into a static HashCodes class.
If you put one into Objects, then the primitive hashCode
methods wouldn't belong in there, defeating your aim
of keeping them together.
Probably we want to have hash code combining methods.
Sigh... nothing is ever easy.
Martin
On Wed, Sep 9, 2009 at 17:40, Joe Darcy<Joe.Darcy at sun.com> wrote:
> Martin Buchholz wrote:
>>
>> Here's a bunch of static hashCode methods for primitives:
>>
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/hashCode/
>>
>
> Hmm, I'd be more inclined to group these methods into Objects as part of a
> "universal hash" functionality.
>
>> This doesn't include a
>>
>> public static int hashCode(object x) { return x == null ? 0 :
>> x.hashCode(); }
>>
>> that I think was also being asked for, and which might be a candidate
>> for Objects.
>
> Yes, I was thinking of that method for Objects.
>
> -Joe
>
> PS This talk of hashing remind me of a small spec cleanup:
> 4245470 algorithm of java.lang.Byte.hashCode() is not specified
> http://bugs.sun.com/view_bug.do?bug_id=4245470
>
More information about the core-libs-dev
mailing list