From: John W Kennedy (firstname.lastname@example.org)
Date: Thu Oct 02 2008 - 21:36:44 CDT
On Oct 2, 2008, at 7:37 PM, Matt Chu wrote:
> 1) There DOES exist language-dependent string equivalence, as well
> as Java's built-in language-independent string equivalence. That is,
> the follow situation exists:
> x = "\uXXXX";
> y = "\uYYYY";
> if (locale == A) then x == y else x != y
In the first place, "x == y" in Java means that x and y are the same
object. In the second place, the definition of x.equals(y) is not
locale-dependent; it means only that the two strings have the same
sequence of 16-bit UTF-16 codes. (In other words, if you want equals()
and hashCode() to work, you /will/ need some kind of normalization.)
> 2) Given that (1) is true and .equals changes based on locale, then
> doesn't that mean I have to override .hashCode in order to maintain
> the Java equals/hashcode contract (i.e. make sure my Collections
> don't break)?
And all this fails, because (1) is not true.
-- John W Kennedy "Compact is becoming contract, Man only earns and pays." -- Charles Williams. "Bors to Elayne: On the King's Coins"
This archive was generated by hypermail 2.1.5 : Thu Oct 02 2008 - 21:40:24 CDT