<i18n dev>  RFR: 8061382: Separate CLDR locale data from JRE locale data
masayoshi.okutsu at oracle.com
Thu Oct 23 00:54:26 UTC 2014
On 10/23/2014 4:52 AM, Naoto Sato wrote:
> Hi Mandy,
> As I wrote in a separate email, my preference is the following module
> This way, they both come under "localedata" (btw, they don't provide
> Locale, but the data for locale sensitive services such as DateFormat,
> so I prefer to keep "localedata" here), and jre/cldr are provider
> names which correspond to names in the system property.
> On 10/22/14, 11:29 AM, Mandy Chung wrote:
>> On 10/20/2014 5:25 PM, Naoto Sato wrote:
>>>> My motive for the question is the naming because the changes mean we
>>>> have jdk.localedata and jdk.localedata.cldr, an arrangement that
>>>> suggests that the CLDR locale data augments the jdk.localedata module.
>>>> It may be that we need to choose more suitable names for these two
>>>> modules and this will impact the source layout.
>>> I think we can rename the original jdk.localedata to
>>> jdk.localedata.jre solely for the legacy JRE locale data, and create
>>> the new jdk.localedata.cldr. Or re-purpose jdk.localedata to represent
>>> the legacy JRE locale data, and newly create jdk.cldrlocaledata for
>>> the CLDR data. Either way they won't suggest the augmentation you
>> I think either CLDR or the legacy locale data is used but not both. As I
>> understand, it's specified via the "java.locale.providers" system
>> property and CLDR is not used by default. CLDR is common locale data
>> repository and "localedata" is implied.
>> One alternative is:
>> I understand from you that the plan is to enable CLDR by default in a
>> future JDK release. The other option of the module names could be:
>> They are providers to the locale SPI and so "jdk.locale" might do.
More information about the jigsaw-dev