-
Notifications
You must be signed in to change notification settings - Fork 5.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8308108: Support Unicode extension for collation settings #14040
Conversation
👋 Welcome back naoto! A progress list of the required criteria for merging this PR into |
Webrevs
|
test/jdk/sun/text/resources/Collator/CollationSettingsTests.java
Outdated
Show resolved
Hide resolved
Co-authored-by: Andrey Turbanov <turbanoff@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good.
Associated CSR also Reviewed.
* will have the specified strength and/or decomposition respectively. If the specified | ||
* setting value is not recognized, strength and/or decomposition will not be | ||
* overridden. | ||
* @apiNote Implementations of {@code Collator} class may produce |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The API should identify the valid values for ks and kk and the corresponding values as passed to setStrength and setDecomposition.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good
@naotoj This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 149 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
* </tbody> | ||
* </table> | ||
* If the specified setting value is not recognized, strength and/or | ||
* decomposition will not be overridden. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
It's the last sentence that bothers me. I understand the setters can't fail but the last sentence of the proposed text makes it sound like invalid settings will be just ignored. So I think this sentence needs to be re-examined as I don't think I understand what it is trying to say now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIUC that's already the existing behavior for any Unicode extension.
Example,
Locale enIsoLoc = Locale.forLanguageTag("en-u-fw-mon");
WeekFields.of(enIsoLoc).getFirstDayOfWeek(); // MONDAY
Locale badExtension = Locale.forLanguageTag("en-u-fw-zzz");
WeekFields.of(badExtension).getFirstDayOfWeek(); // SUNDAY
If the value for a Unicode extension is invalid, they are simply ignored. In this case 'zzz' is not recognized and thus can not overhaul the first day of the week.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
I went through the latest javadoc but the last sentence is still confusing. I think the part that is missing is the method doesn't make it clear up front that it gets requested locale and then attempts to set its strength and decomposition if recognized. If this were clear in the first part of the method description then it is okay to say that the returned Collator might not have the expected strength and decomposition. |
Thanks, Alan. Clarified the method doc based on your suggestion. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for persisting with this to get the wording clear, the latest version looks good.
/integrate |
Going to push as commit 27ba8bd.
Your commit was automatically rebased without conflicts. |
This change intends to interpret the BCP47 U extension wrt collation settings in the given
Locale
, then applies them to the created instances in the 1-arg factory method inCollator
. A corresponding CSR has also been drafted.Progress
Issues
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/14040/head:pull/14040
$ git checkout pull/14040
Update a local copy of the PR:
$ git checkout pull/14040
$ git pull https://git.openjdk.org/jdk.git pull/14040/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 14040
View PR using the GUI difftool:
$ git pr show -t 14040
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/14040.diff
Webrev
Link to Webrev Comment