<i18n dev>  RFR 8038436: Re-examine the mechanism to determine available localedata and cldrdata
naoto.sato at oracle.com
Fri Aug 22 23:23:47 UTC 2014
On 8/22/14, 3:56 PM, Mandy Chung wrote:
> A service config file can contain multiple provider implementation
> classes. JDI connector is one example:
> There may be some bug somewhere.
I know a single service config file can contain multiple implementation
classes. However in this case, each jar file contains only either of
those two provider types. For example, localedata.jar only contains
JRENonENLocaleDataMetaInfo. So if the service config file contained
CLDRLocaleDataMetaInfo entry, that would fail on loading.
>> 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
>> 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?
If the code weren't catching the exception, several existing regression
tests would fail, such as,
test/java/util/concurrent/atomic/AtomicUpdaters.java which installs a
Policy that allows no permissions. Do you still need extra test case for
it which would do the same testing?
>>> 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?
There already are test cases that examine localedata/cldrdata locale
data. Maybe what could be done is to create a test to obtain available
locales without localedata.jar/cldrdata.jar, and confirm it only
contains en* locales. Are there any way to run regression tests that can
run *without* installed JDK extensions?
More information about the i18n-dev