On 26/07/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
Some hashCode functions are actually very *hot* methods (e.g. String) In this case I think that a bad but fast hashCode() could be better than good but slow. May be I'm wrong but only tests can show the difference. So if you have tests, I'm +1
Speaking of which ... I recall seeing an interesting behaviour back in the Java 1.1 days when the hashCode() of a String used all the characters when the String was less than a certain threshold (about 100 chars?) and then for larger sizes, took a stride of about every tenth character. It was a real problem when I was doing a bunch of hash inserts on long similar names that often only changed at the end; so com.example.some.thing.here.ClassA and com.example.some.thing.here.ClassB ended up having the same hash because the stride was in effect and so didn't see the difference between the two :-) What effect would there be if we were communicating (via RMI) with an implementation of a remote VM that isn't harmony? I.e.,if we have a String "asdfasdfasdf" which hashes to (say) 8 on a Harmony VM, and a remote implementation uses a hash of 12 for the same value, would that cause any problems in an RMI layer? Do we care about such a scenario? Alex. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
