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

[Naoto Sato]

Thank you, Mandy, Masayoshi, and Alan for your comments. I revised the 
changes based on your suggestions as follows:

http://cr.openjdk.java.net/~naoto/8038436/webrev.4/

Here are the changes since webrev.3

- CLDRLocaleProviderAdapter.java: modified to throw 
UnsupportedOperationException with the actual exception set to its 
"cause." More descriptive comment on it.

- *ProviderImpl.java: Removed changes to them. Initial thought was to 
make them performant by changing the langtags to static, but it turned 
out that wasn't necessary.

- JREENLocaleDataMetaInfo.java/JRENonENLocaleDataMetaInfo.java: Renamed 
to EnLocaleDataMetaInfo and NonEnLocaleDataMetaInfo respectively for 
readability. String constants are wrapped for readability as well. Used 
getOrDefault() for getSupportedLocaleString().

- Added test cases for SecurityException and JRE's supported locales for 
each service.

I'd appreciate it if someone in the build-dev could review the makefile 
changes.

Naoto

On 8/22/14, 11: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