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

[Erik Joelsson]

 From a build point of view, this looks fine.

/Erik

On 2014-08-28 20:34, Naoto Sato wrote:
> 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