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

[Naoto Sato]

Thank you, Magnus, Erik for the comments. My comments inline below:

On 10/31/14, 6:32 AM, Erik Joelsson wrote:
>
> On 2014-10-31 14:21, Magnus Ihse Bursie wrote:
>>
>> 1) I do not like how gensrc/Gensrc-jdk.localedata.cldr.gmk is included
>> in CreateJars.gmk -- it should not be there. The reason is to get the
>> CLDRVERSION which is defined in that file. I'd like to address that,
>> either by extracting the CLDRVERSION out into a separate file that can
>> be included more sanely into both the Gensrc file and CreateJars, or
>> by some other solution. It seems that the actual version string is
>> only used in CreateJars.gmk, in Gensrc-jdk.localedata.cldr.gmk it is
>> only used to create the path to the cldr files. However, there is
>> currently only a single directory that could possibly be used as the
>> src directory. As long as that is the case, the CLDRVERSION is not
>> strictly needed in the Gensrc file. Is this code some remnant of an
>> old system that was supposed to support multiple versions? If so, do
>> you think it is likely to come back, or can we safely assume that the
>> code base only has a single version of cldr checked in at a time?
>>
> CreateJars.gmk is soon going away completely (in Jigsaw M2) and the
> replacement has no need for knowing CLDRVERSION, so this will soon be
> fixed.

As to the CLDRVERSION, my intention was to embed the CLDR version number 
in the source path for easier lookup of the CLDR version number (CLDR 
data are merely a set of .xml files where no version is associated by 
itself).

As to the multiple CLDR releases support, I don't think of that in the 
near future.

>> 2) The comment at the EXCLUDE_FILE says:
>>  # Exclude BreakIterator classes that are just used in compile process
>> to generate
>>  # data files and shouldn't go in the product
>> Normally, java code that is only used during build, is not stored in
>> the src tree, but in make/src instead. Do you think it is possible to
>> move the BreakIteratorRules_th.java there, so we can skip the explicit
>> exclude?
>>
> This is a cleanup I would like to get done.

Ditto.

Naoto