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.da...@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 >
