[9] RFR: 8061382: Separate CLDR locale data from JRE locale data

[Magnus Ihse Bursie]

On 2014-10-23 22:05, Naoto Sato wrote:
> I revised the fix according to the suggestions I got. The main change 
> is to rename the name of the locale data modules. Now we have two as 
> follows:
>
> - jdk.localedata.classic: Legacy locale data
> - jdk.localedata.cldr: CLDR locale data
>
> Revised webrev is located at:
>
> http://cr.openjdk.java.net/~naoto/8061382/webrev.01/

I have looked at the makefile changes only, and they look good.

However, when doing so I noticed some parts that could do with further 
cleaning up. This is not something I'm suggesting you do in this fix, 
but I'm hijacking this thread to hear if you have some input on these 
issues. :-)

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?

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?

/Magnus