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
8275721: Name of UTC timezone in a locale changes depending on previous code #6709
Conversation
|
Webrevs
|
@@ -28,6 +28,7 @@ | |||
import static sun.util.locale.provider.LocaleProviderAdapter.Type; | |||
|
|||
import java.text.MessageFormat; | |||
import java.time.ZoneId; |
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.
nit, the import is not used?
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.
Right. Removed.
} | ||
|
||
@Test(dataProvider="locales") | ||
public void test_ChineseTimeZoneNames(Locale testLoc, Locale resourceLoc) { |
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.
Does this test exercise the problem as in the original test? Do we need a test to reproduce the calling sequence as the original test?
The original issue seems to me was that the names were dependent on the order of calls, due to the name being cached. That is, if utcNameIn("zh-Hant-HK") is called first, subsequent call utcNameIn("zh-MO") would get the cached name from the call (zh-Hant-HK), but if the later is called first, it would not have the problem, that is, the following would return a correct name (協調世界時間):
utcNameIn("zh-MO"); utcNameIn("zh-Hant-HK"); utcNameIn("zh-MO");
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.
協調世界時間
is actually coming from COMPAT
provider, which is wrong. The expected name 世界標準時間
in CLDR is in zh-Hant
resource bundle which is not available in COMPAT
provider. Thus, comparing zh-MO
and zh-Hant
names effectively asserts that the name is correctly coming from CLDR
provider. I confirmed that this regression test did fail with the runtime without the proposed fix.
@naotoj This change now passes all automated pre-integration checks. 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 85 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.
|
/integrate |
Going to push as commit 543d1a8.
Your commit was automatically rebased without conflicts. |
Fixing time zone name provider for CLDR. In some cases, COMPAT's
UTC
display names were incorrectly substituted for CLDR. The reason it worked fine afterzh-Hant-HK
was that by loading names forzh-Hant-HK
, the names forzh-Hant
were cached and hit for the followingzh-MO
name retrieval.Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/6709/head:pull/6709
$ git checkout pull/6709
Update a local copy of the PR:
$ git checkout pull/6709
$ git pull https://git.openjdk.java.net/jdk pull/6709/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 6709
View PR using the GUI difftool:
$ git pr show -t 6709
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/6709.diff