<div dir="ltr"><div dir="ltr"><div dir="ltr">On Wed, Apr 24, 2019 at 5:39 PM Stuart Marks <<a href="mailto:stuart.marks@oracle.com">stuart.marks@oracle.com</a>> wrote:<br></div><div dir="ltr"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">By "quality" hash code, do you mean a cryptographic hash?</blockquote><div><br></div><div>No, definitely not. I just mean things like bit dispersion/avalanche and better (sub-crypto) collision resistance.</div><div><br></div><div>The root problems I'm aware of with Object.hashCode() being pulled beyond its core purpose (providing bits for HashMaps to stir up and use) are:</div><div><br></div><div>* It can't be seeded</div><div>* Compositing a hash code from a tree of data has to keep collaring down to 32 bits over and over, putting the burden on "everyone" to know how to do that well</div><div>* You can't get away from the preponderance of mediocre functions we're already stuck with, as noted</div><div><br></div><div>I'm all for implementing something better than times-31-plus. AutoValue happens to have been using times-1000003-xor for most of its lifespan, and I wouldn't be at all surprised if there's a better default choice. The only thing I'm arguing against is letting users customize the function; I think that would be a mistake.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Other applications might want to use this API for convenience, or cleaner code, <br>
or something, but which might want to use their own hash reduce function in <br>
order to preserve compatibility.</blockquote><div><br></div><div>Of course, by all that is sensible, either you should never have specified your hashCode() behavior or your users should never have depended on it. Someone did something wrong -- which isn't enough reason to tell those people "you're screwed!", but it seems totally reasonable to me that if you're stuck with your old hash function definition, then you're just stuck with your old hash function implementation too. That's not being screwed, that's just keeping on doing what you were doing.</div><div><br></div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div style="line-height:1.5em;padding-top:10px;margin-top:10px;color:rgb(85,85,85);font-family:sans-serif"><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(213,15,37);padding-top:2px;margin-top:2px">Kevin Bourrillion |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(51,105,232);padding-top:2px;margin-top:2px"> Java Librarian |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(0,153,57);padding-top:2px;margin-top:2px"> Google, Inc. |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2px"> <a href="mailto:kevinb@google.com" target="_blank">kevinb@google.com</a></span></div></div></div></div></div></div></div></div></div>