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

[Mandy Chung]

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
>> src/jdk.localedata/share/META-INF/services/sun.util.locale.provider.LocaleDataMetaInfo 
>>
>
> 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
>
> sun.util.locale.provider.JRENonENLocaleDataMetaInfo
> sun.util.cldr.CLDRLocaleDataMetaInfo
>
> 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:
http://hg.openjdk.java.net/jdk9/dev/jdk/file/74078474d9bd/src/jdk.jdi/share/classes/META-INF/services/com.sun.jdi.connect.Connector

There may be some bug somewhere.
>
>>
>> sun/util/cldr/CLDRLocaleProviderAdapter.java
>>     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 
> there.

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 
diagnosability.
>
>>
>> sun/util/locale/provider/JRELocaleProviderAdapter.java
>>     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?

Mandy