<i18n dev> [9] RFR: 8061382: Separate CLDR locale data from JRE locale data

[Naoto Sato]

Hi Mandy,

As I wrote in a separate email, my preference is the following module names:

jdk.localedata.jre
jdk.localedata.cldr

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.

Naoto

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 refer.
>
> 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:
>     jdk.cldrdata
>     jdk.localedata
>
> 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:
>      jdk.locale.legacy
>      jdk.locale.cldr
>
> They are providers to the locale SPI and so "jdk.locale" might do.
>
> Mandy
>