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

[Naoto Sato]

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:
> 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.

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
>> 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.

Will do.

>> 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?

Naoto