Have to agree .equals is the way to go, since correctness of == is too reliant on what must be considered implementation optimisations in the parser.
Benchmarking in JVM is notoriously difficult, but it does look like there is no gross difference, which should kill any objections to doing it correctly. Since I recently spend far to long researching this for an unrelated problem I'll add my 10c to the detail discussion. On 10/08/10 01:23, Chad La Joie wrote: > Not necessarily, there are a number of not equal checks in there that > should, in theory, perform better if you only use == only. In such a > case, the use of != will just be a single check while !equals() will > result in a char-by-char comparison. Actually, the next thing String.equals tests is length equality - so character comparison will only be reached if the strings are the same length. Since the char by char comparison returns on the first mismatch, then only same length strings with shared prefixes will show the expected slowness. (namespace URIs are likely to share prefixes, but I think are not particularly likely to be the same length, unless actually equal)... thus String.equals is only likely to be slow where comparing long distinct but equal strings (so intern or alternative string pooling techniques needed for == benefit .equals without all the nasty loopholes: even if .equals is occasionally slow, at least it is always right). In circumstances where doing repeated tests with many length and prefix matches, adding a hash code inequality test ((s1.hashCode()== s2.hashCode())&&s1.equals(s2)) could prevent practically all char-by-char checks for !equal cases (but if the same strings are never repeatedly used, the hash code calculation could be an issue; nb intern results in hash calculation for all strings anyway)... pooling is still needed to speed up matches for equality though. Re VM options I would feel -server is definitely the right test bed, both because of the more aggressive JIT, and also because the code is likely to see heaviest real world cases in -server VMs.
