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
