JDK-8008577 : Use CLDR Locale Data by Default
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2013-02-20
  • Updated: 2017-05-17
  • Resolved: 2015-06-24
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
Related Reports
Blocks :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Sub Tasks
JDK-8167322 :  
Description
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.
Comments
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

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