-
Bug
-
Resolution: Fixed
-
P3
-
17, 18, 19
-
b19
-
b21
-
generic
-
generic
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8302183 | 17.0.8-oracle | Yoshiki Sato | P3 | Resolved | Fixed | b01 |
JDK-8305375 | 17.0.8 | Goetz Lindenmaier | P3 | Resolved | Fixed | b01 |
A DESCRIPTION OF THE PROBLEM :
When using the locale 'nb', information like weekdays, monthname etc. is not correct when a locale of 'nn' also has been used first. By not correct I mean they are expressed as some default language eg. english.
I believe that the reason for this bug is a regression for commit https://github.com/openjdk/jdk/commit/f6e54f2f9a27d08b8789244d86354167f1478bb5
Here nb.xml and other files have lost a lot of information. It was deleted in above state commit. Somehow in the language bundle selection there is code that tries to get the correct bundle for a given locale. This ends up in a bad state and english locale data is the result. I believe that the nb.xml should get the data back.
REGRESSION : Last worked in version 14
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
You just need to run some code to reproduce this.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
nn: [, sø., må., ty., on., to., fr., la.]
nb: [, søn., man., tir., ons., tor., fre., lør.]
ACTUAL -
nn: [, sø., må., ty., on., to., fr., la.]
nb: [, Sun, Mon, Tue, Wed, Thu, Fri, Sat]
---------- BEGIN SOURCE ----------
System.out.println("nn: " + Arrays.deepToString(DateFormatSymbols.getInstance(Locale.forLanguageTag("nn")).getShortWeekdays()));
System.out.println("nb: " + Arrays.deepToString(DateFormatSymbols.getInstance(Locale.forLanguageTag("nb")).getShortWeekdays()));
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
No known workaround.
FREQUENCY : always
When using the locale 'nb', information like weekdays, monthname etc. is not correct when a locale of 'nn' also has been used first. By not correct I mean they are expressed as some default language eg. english.
I believe that the reason for this bug is a regression for commit https://github.com/openjdk/jdk/commit/f6e54f2f9a27d08b8789244d86354167f1478bb5
Here nb.xml and other files have lost a lot of information. It was deleted in above state commit. Somehow in the language bundle selection there is code that tries to get the correct bundle for a given locale. This ends up in a bad state and english locale data is the result. I believe that the nb.xml should get the data back.
REGRESSION : Last worked in version 14
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
You just need to run some code to reproduce this.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
nn: [, sø., må., ty., on., to., fr., la.]
nb: [, søn., man., tir., ons., tor., fre., lør.]
ACTUAL -
nn: [, sø., må., ty., on., to., fr., la.]
nb: [, Sun, Mon, Tue, Wed, Thu, Fri, Sat]
---------- BEGIN SOURCE ----------
System.out.println("nn: " + Arrays.deepToString(DateFormatSymbols.getInstance(Locale.forLanguageTag("nn")).getShortWeekdays()));
System.out.println("nb: " + Arrays.deepToString(DateFormatSymbols.getInstance(Locale.forLanguageTag("nb")).getShortWeekdays()));
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
No known workaround.
FREQUENCY : always
- backported by
-
JDK-8302183 Locale information for nb is not working properly
- Resolved
-
JDK-8305375 Locale information for nb is not working properly
- Resolved
- relates to
-
JDK-8258794 Update CLDR to version 39.0
- Resolved
-
JDK-8317443 StackOverflowError on calling ListFormat::getInstance() for Norwegian locales
- Resolved
- links to
-
Commit openjdk/jdk17u-dev/f53661b1
-
Commit openjdk/jdk/3d07b3c7
-
Review openjdk/jdk17u-dev/1220
-
Review openjdk/jdk/8394
(3 links to)