<i18n dev> RFR: 8308108: Support Unicode extension for collation settings [v3]

Naoto Sato naoto at openjdk.org
Fri May 19 16:46:55 UTC 2023


On Fri, 19 May 2023 07:59:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added a table for possible BCP47 values and their mappings
>
> src/java.base/share/classes/java/text/Collator.java line 264:
> 
>> 262:      * </table>
>> 263:      * If the specified setting value is not recognized, strength and/or
>> 264:      * decomposition will not be overridden.
> 
> The proposed update looks okay except for the last part "If the specified setting value is not recognized, strength and/or decomposition will not be overridden". I thin this could be clearer.
> If I understand correctly, if the Unicode locale type for the given Locale might have a strength level and decomposition mode and this method makes a best effort to return a Collator with the expected level and mode. If so, then I think the javadoc needs to make this a bit clearer. Also, if the factory method returns a Collator that doesn't do what I asked, can I call setStrength/setDecomposition to change it?

I don't think there is any chance that the factory method returns a Collator that fails to meet the settings in the locale, because setStrength()/setDecompositon() with valid values never fail. So the returned instance will always have the requested strength/decomposition. Does this answer your question?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14040#discussion_r1199167454


More information about the i18n-dev mailing list