JDK-6336885 : RFE: Locale Data Deployment Enhancements
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.text
  • Affected Version: 5.0,6,7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,solaris_2.5.1
  • CPU: generic,sparc
  • Submitted: 2005-10-14
  • Updated: 2022-08-10
  • Resolved: 2012-09-05
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 8
8 b55Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
Most internationalization components in Java are designed to be locale data driven. For example, if date/time format strings (e.g., "yyyy-MM-dd") and calendar component names (e.g., month names) for a locale are added to the Java runtime, java.text.DateFormat produces desired date and time output for the targetted local users without implementing a DateFormat subclass. In Java SE, however, the process for defining and deploying such locale data isn't established. Currently, you have to handcraft Java programs only to define locale data. The lack of the process makes it difficult for our localizers and licensees to add more locale support. Even maintenance of existing locale data is difficult for localizers because they are often non-Java programmers.

This RFE should address the following items.

- Define an input format for defining locale dependent data. LDML (Locale Data Markup Language) is preferred because it's a standard defined by the Unicode consortium. The input format must be committed to by Sun as the public interface for defining locale data.

- Develop a tool to generate locale data files for the runtime from the input format, assuming that interpreting an LDML file at runtime isn't feasible due to performance and footprint issues. The output file format shall remain Sun private for future extensions.

- Develop a mechanism to deploy locale data. (We may utilize Modules - JSR277 or brew our own.)

Comments
Run the new test developed for JEP 127 with latest JPRT build and JDK8 b62.
29-10-2012

SUGGESTED FIX http://hg.openjdk.java.net/jdk8/tl/jdk/rev/131a683a2ce0
21-08-2012

EVALUATION Unicode consortium has been releasing the CLDR (http://cldr.unicode.org/), which contains the XML based locale data that are agreed upon major entities in the world. They are becoming the de-facto standard for the locale data. In order to address the locale data maintenance issue, incorporating the CLDR locale data into the JDK would be the most preferred way to resolve it. The CLDR's XML based locale data should be converted to some internal format at the build time for the runtime performance. We will also provide a locale data adapter which reflects the underlying OS's locale data, as well as the current user's customization on underlying OS's settings. In JDK8, we will have 4 distinct locale data sources. The above two sources are CLDR and HOST respectively, and we already have JRE which is the existing locale data in the JRE, and SPI which is the locale data coming from SPI implementations. The user will be able to specify his/her preference on which locale data has priority than the others by spcifying a new system property "java.locale.providers." S/he can declare his/her preference in that system property by, for example, "HOST,SPI,CLDR,JRE." which translates to host locale data settings comes first, then SPI, CLDR, and JRE accordingly.
13-07-2012

EVALUATION Individual functionality items, such as UCA support, need to be identified.
14-10-2005