<i18n dev>  RFR 8038436: Re-examine the mechanism to determine available localedata and cldrdata
masayoshi.okutsu at oracle.com
Mon Sep 1 06:46:22 UTC 2014
Do we need availableLocalesTests() of Bug8038436.java? I think it's
rather a burden to maintain the hard-coded tags in the test.
Otherwise, the fix looks good to me.
On 8/30/2014 6:07 AM, Naoto Sato wrote:
> I incorporated the suggestions from Mandy and Alan. Also one change
> since the last webrev was to revert the hard-coding of the supported
> locales list back to the one which dynamically generates the lists at
> the build time. I initially thought static listing of locales would be
> less complex as to the build script/makefile, but on second thought
> it's less evil than possible future regressions.
> Please review:
> On 8/28/14, 11:34 AM, Naoto Sato wrote:
>> Thank you, Mandy, Masayoshi, and Alan for your comments. I revised the
>> changes based on your suggestions as follows:
>> 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
>> On 8/22/14, 11:46 AM, Naoto Sato wrote:
>>> Please review the changes for the following issue:
>>> The proposed changes are located at:
>>> 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.
More information about the i18n-dev