Create a tool to convert LDML (Locale Data Markup Language) files into a format
usable directly by the runtime library, define a way to package the results
into modules, and then use these to incorporate the de-facto standard locale
data published by the Unicode Consortium's CLDR project into the JDK.
- Develop a tool to generate locale data files for the runtime from the LDML
format, assuming that interpreting LDML at runtime isn't feasible due to
performance constraints. The output file format shall be opaque so as to
allow for future extensions.
- Develop a mechanism to package and install locale data in the form of
- Support some locale elements from underlying platforms. For example, if
the user preference for the date format specifies the Japanese calendar
then the Java runtime should use that information to select the Japanese
calendar as the default calendar. (See 6337471: desktop/system locale
- Provide a mechanism to manage the user's locale data preference through
some kind of UI, in an application (through an SPI), or at the OS level
(e.g., through the Java control panel in Windows).
Need to verify that the installed locale data is correctly returned via
locale-sensitive APIs such as `DateFormat`/`NumberFormat`, etc.
Risks and Assumptions
Since the JDK's collation API does not yet support the Unicode Collation
Algorithm, on which LDML is based, collation data contained in LDML files will
not be supported.
- Compatibility: Some of the locale data in CLDR won't be compatible with the
JDK's own locale data. There should be some mechanism for users to specify
- Localization: Developers working on localization will be able to add/modify
locale data from CLDR in an established way.