<i18n dev> [9] RFR 8038436: Re-examine the mechanism to determine available localedata and cldrdata

[Masayoshi Okutsu]

Here are my comments.

- Looks like this change removed the 8055088 fix for BreakIteratorInfo 
optimization.

- The langtags field in each *Impl class should be volatile.

- DateFormatProviderImpl has static langtags to be shared by some other 
*Impl. But JRE and CLDR have different sets of language tags.

- Now language tags are hard coded, but that will be error prone when 
adding or changing locale data. There should be a test case for checking 
consistency between existing resource bundles and the hard-coded tags 
(to detect any missing locales in the hard-coded lists).

- JREENLocaleDataMetaInfo: the first upper case part looks like one word 
JREEN. JreEnLocaleDataMetaInfo may be better. It's not consistent with 
others, though.

Masayoshi


On 8/23/2014 3:46 AM, Naoto Sato wrote:
> Hello,
>
> Please review the changes for the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8038436
>
> The proposed changes are located at:
>
> http://cr.openjdk.java.net/~naoto/8038436/webrev.3/
>
> The idea is to introduce an SPI so that supported locales are 
> dynamically searched at runtime, not depending on the existence of 
> physical jar files.
>
> I'd appreciate it if build folks could review the makefile related 
> changes, i18n forks to review locale framework files, and Mandy from 
> modularization point of view.
>
> Naoto