P4
The Collator specification needs to be beefed up with some clarifications.
* Although it's declared as Comparator<Object>, it appears that it is only possible to use a Collator to compare Strings. (However, I'm not entirely sure this is true. This should be verified.) I don't think we want to try to expand Collator to allow comparison of other objects, so the spec should more explicit about allowing only comparison of Strings. The declaration of Comparator<Object> should be justified, if only for "historical reasons" or some such.
* There is a stipulation that CollationKey objects obtained from different Collators cannot be compared. Of course, they CAN be compared, and something should happen. The specification should be clearer about this. I imagine that an exception is thrown, or possibly that the result of such a comparison is unspecified. This probably also warrants updating the CollationKey specification.
* As Collator appears that it's semantically a Comparator<String>, the issue arises of whether or not it's consistent with equals. My belief is that any Collator is typically inconsistent with equals. This is because the Collator's strength specifies that it ignores certain character details (case, accents, etc.), and its decomposition mode specifies that certain decomposition transformations be performed on the string before collation. Thus, different strings can collate as equivalent, implying that the Collator can be inconsistent with equals. In fact I believe that the value provided by a Collator is that it does these things, thus the most common case will be that a Collator is inconsistent with equals. (A Collator with a strength of IDENTICAL and a decomposition mode of NO_DECOMPOSITION might be consistent with equals, but I'm not sure.) In any case, if the preceding assumptions are true, then Collator also deserves the inconsistent-with-equals warning.
* Although it's declared as Comparator<Object>, it appears that it is only possible to use a Collator to compare Strings. (However, I'm not entirely sure this is true. This should be verified.) I don't think we want to try to expand Collator to allow comparison of other objects, so the spec should more explicit about allowing only comparison of Strings. The declaration of Comparator<Object> should be justified, if only for "historical reasons" or some such.
* There is a stipulation that CollationKey objects obtained from different Collators cannot be compared. Of course, they CAN be compared, and something should happen. The specification should be clearer about this. I imagine that an exception is thrown, or possibly that the result of such a comparison is unspecified. This probably also warrants updating the CollationKey specification.
* As Collator appears that it's semantically a Comparator<String>, the issue arises of whether or not it's consistent with equals. My belief is that any Collator is typically inconsistent with equals. This is because the Collator's strength specifies that it ignores certain character details (case, accents, etc.), and its decomposition mode specifies that certain decomposition transformations be performed on the string before collation. Thus, different strings can collate as equivalent, implying that the Collator can be inconsistent with equals. In fact I believe that the value provided by a Collator is that it does these things, thus the most common case will be that a Collator is inconsistent with equals. (A Collator with a strength of IDENTICAL and a decomposition mode of NO_DECOMPOSITION might be consistent with equals, but I'm not sure.) In any case, if the preceding assumptions are true, then Collator also deserves the inconsistent-with-equals warning.