Bug ID: JDK-8008577 Use CLDR Locale Data by Default

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 9
9 b71Fixed

This issue tracks the implementation and actual code integration into the repository for the JEP 252.
---

Currently, CLDR locale data are available only when the user explicitly specifies it in a system property, e.g., 

java.locale.providers=JRE,SPI,CLDR

So although the JRE contains the CLDR locale data, it is not used at all by default.

This issue is to enable the CLDR locales without having the user specify this system property, but still have the equivalent locale provider adapter preference order as the above example.

URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/22f901cf304f User: lana Date: 2015-07-01 21:31:59 +0000
01-07-2015
Actually, I think the bug is on your side, as after the changes it now reports CEST (Central European Summer Time) even for dates in December, where previously we had the switch in March and October, as you can see in the snippet above. If I define -Djava.locale.providers=JRE,SPI it works as it did before again.
25-06-2015
Hi, this change causes a test failure in Nashorn. If you go to jdk9/nashorn/make and issue "ant test" you'll see: [testng] Test test/script/basic/NASHORN-627.js failed at line 1 - [testng] expected: 'Sun Dec 21 1969 00:00:00 GMT+0100 (CET) -954000000 1969-12-20T23:00:00.000Z' [testng] found: 'Sun Dec 21 1969 00:00:00 GMT+0100 (CEST) -954000000 1969-12-20T23:00:00.000Z' You can see the expected test output in jdk9/nashorn/test/script/basic/NASHORN-627.js.EXPECTED. Basically, every case where previously it said "CET" now it says "CEST". Note: the expected test output does contain some CEST timezones too: Sat Mar 26 2011 17:00:59 GMT+0100 (CET) 1301155259000 2011-03-26T16:00:59.000Z Sun Mar 27 2011 17:00:59 GMT+0200 (CEST) 1301238059000 2011-03-27T15:00:59.000Z ... Sat Oct 29 2011 17:00:59 GMT+0200 (CEST) 1319900459000 2011-10-29T15:00:59.000Z Sun Oct 30 2011 17:00:59 GMT+0100 (CET) 1319990459000 2011-10-30T16:00:59.000Z I lack the expertise to decide if this is a bug on your part, or is this an expected change in behaviour and we need to adjust the test; please advise.
25-06-2015
URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/22f901cf304f User: naoto Date: 2015-06-24 23:43:18 +0000
24-06-2015
Proposed preferred order: "CLDR,JRE,SPI"
25-03-2014
Work stopped for JDK8. Tentative patch (so far) updated.
22-07-2013
Prototyped and tested, but it caused more failures, which are valid b/c in some locales like ar_SA, only CLDR has resources. That means the compatibility risk may not be so small for this change. Probably not worth trying in JDK8, but in JDK9 with Jigsaw modules.
27-02-2013
Attached a tentative fix.
27-02-2013

Blocks :	JDK-8043554 - JEP 252: Use CLDR Locale Data by Default
Duplicate :	JDK-8114833 - java.time.format.DateTimeFormatter does not work as documented
Relates :	JDK-8153041 - Remove unused redundant parameter in CLDRConverter
Relates :	JDK-8138613 - Remove SPI locale provider adapter from the default provider list
Relates :	JDK-8131041 - Garbage in output of DecimalFormat
Relates :	JDK-8167143 - CLDR timezone parsing does not work for all locales
Relates :	JDK-6712094 - DateFormat produces incorrect short date pattern for en_GB locale
Relates :	JDK-8252383 - NumberFormat.parse fails with some locale providers
Relates :	JDK-8130845 - Change to CLDR Locale data in JDK 9 b71 causes SimpleDateFormat parsing errors
Relates :	JDK-8129881 - JDK-8008577 breaks Nashorn test
Relates :	JDK-8134250 - Create unit tests for CLDR unique features
Relates :	JDK-8244843 - [JDK 8u] JapanEraNameCompatTest fails