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

Masayoshi Okutsu masayoshi.okutsu at oracle.com
Mon Aug 25 08:41:54 UTC 2014

Here are my comments.

- Looks like this change removed the 8055088 fix for BreakIteratorInfo 

- 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.


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

More information about the i18n-dev mailing list