Tune String's hashCode() + equals() [was: Need reviewer for forward port of 6815768 (File.getXXXSpace) and 6815768 (String.hashCode)]

Marek Kozieł develop4lasu at gmail.com
Thu Mar 4 20:31:20 UTC 2010

Few explanations:
> Intersting alternative, but I'm afraid, this is against the spec.
> Shifting all 0's to 1 would break String's hash definition:  h = 31 * h + val[i++].
Yes it does, any way i think spec is to tight here. Do we really need
hash of each value even if String have length like 600000?
there is noting good coming from it in my opinion.
Did any one saw at least one code relaying on that ?
Btw. Same come with .compare

private static final long isHashBijection= 0x8000000000000000L;
should be fine

Second sample would work only if hash would be set in constructor so
even 0 would be valid hash.

Maybe I'm wrong but if most cases when hash should be count is String
concatenation then we could make it +/-
> a.hash+b.hash*powderOf31[a.length()]
so it would not consume so much time.

Intern string do not need hash codes co comparing cos they have same
address, so first loop would return true if they are equal, after this
we need only to check if they are not equal:
> if (isIntern() && anotherString.isIntern()) return false;

Have in mind that adding additional fields to string might be not an
option, because memory lost this way may have great impact on average
application efficiency.
Pozdrowionka. / Regards.
Lasu aka Marek Kozieł


More information about the core-libs-dev mailing list