<i18n dev>  RFR 8038436: Re-examine the mechanism to determine available localedata and cldrdata
mandy.chung at oracle.com
Fri Aug 22 22:56:36 UTC 2014
On 8/22/14 3:37 PM, Naoto Sato wrote:
>> I wonder ifavailableLanguageTags andgetSupportedLocaleString
>> should return a list or an array of String (see comment below).
>> There are two provider implementations for
>> sun.util.locale.provider.LocaleDataMetaInfo and two service config
>> files as you want to put them in cldrdata.jar and localedata.jar.
>> I wonder if you want to merge them into a single service config
>> for now until you decide to separate them into separate modules
>> in the future.
>> You could simply put it under
> I tried to merge the config file, but it seems not possible to me to
> have two implementation definitions in a single file, e.g., if the
> config file has two entries
> and localedata.jar/cldrdata.jar have one on those each, ServiceLoader
> lookup failed with the exception (sorry forgot the actual name)
> saying, e.g., CLDRLocaleDataMetaInfo cannot be instantiated from
> localedata.jar. Thus I had to have two service config files.
A service config file can contain multiple provider implementation
classes. JDI connector is one example:
There may be some bug somewhere.
>> line 67: why do you silently ignore any exception? In that
>> case, it will throw UOE in line 71. Is UOE caught somewhere?
>> Assume there is a good reason to ignore the exception,
>> can you add comment to explain it?
> UOE is caught in JRELocaleProviderAdapter. Will add some more comments
Is it the SecurityException you try to catch? perhaps you should throw
UOE directly at line 68 with the exception as the cause for better
>> line 391: what exceptions do you expect to be caught here?
>> Do you have a test case for this to demonstrate why you
>> have to ignore the exception?
> The one we have been discussing: AccessClassInPackage security
> exception for sun.util.locale.provider classes from
> localedata.jar/cldrdata.jar. Anyway, I followed the
> ResourceBundle.loadBundle()'s behavior here, where it ignores any
> Exception instances.
Can you add that test case?
>> When you have an image build, it'd be useful to test without
>> cldrdata.jar and localedata.jar from the extension directory
>> and run the tests to use the default EN locale.
> Although I don't have any regression tests, I manually tested such
> situations and confirmed it worked correctly.
Do you mean that the existing regression tests never load cldrdata.jar
and localedata.jar? If so, that matches my suggestion to run them on a
JDK image without cldrdata.jar and localedata.jar and they should pass?
More information about the i18n-dev