<i18n dev> [8]: diff patch for jdk test on a non US platform

Tue Nov 5 22:31:12 PST 2013

HI

To add a little bit more of clarity for the i18n problems in the ResourceBundle 
tests, joined is an extract from the log of their failures before I fixed them 
for the non US Locale case. Sorry for not having joined this log before.

HTH

Francis

Le 06/11/2013 00:43, Naoto Sato a écrit :
> For those tests that are locale sensitive, basic approach should be like:
>
> Locale defaultLocale = Locale.getDefault();
> try {
>     Locale.setDefault(<whatever locale the test wants>);
>
>     <body of the test>
>
> } finally {
>     Locale.setDefault(defaultLocale);
> }
>
> However, it looks to me that those tests in ResourceBundle are already capable 
> of whatever the default locale is, so the test failure needs to be 
> investigated and fixed, not just by setting the locale to Locale.US.
>
> Naoto
>
> On 11/5/13, 3:27 PM, Stuart Marks wrote:
>>
>>
>> On 11/4/13 7:39 PM, Francis ANDRE wrote:
>>> Stuart. the jtreg jdk test should pass OK on all platforms where
>>> OpenJDK could
>>> be build.
>>
>> Yes. On this, we agree. At least, all the tests should pass, on
>> platforms and locales that OpenJDK supports. It looks like localizations
>> are present in OpenJDK for de, es, fr, it, ja, ko, pt_BR, sv, zh_CN, and
>> zh_TW, so all the tests should pass when set to any of these locales.
>>
>> I imagine that your system is set to the French locale, and you observed
>> test failures. You're correct in pointing out that this is a problem.
>> The first thing we need to do is to file a set of bugs on the test
>> failures, and then we need to figure out how to deal with the test
>> failures. (More below.)
>>
>>> So tests that test the localization feature of the jdk should be
>>> localized, otherwise they will failed on non US platform.
>>
>> Two points: first, not all of these tests are tests of localization
>> features of the jdk, and second, localizing the tests is not the correct
>> approach for fixing the tests.
>>
>> To be absolutely clear, in my statement above (and in my previous
>> messages) I'm using "localize" in a very specific fashion. That is, to
>> localize means to modify the code so that its message strings are loaded
>> from a resource bundle, or perhaps from some data structure, instead of
>> being hardcoded. (There are probably other kinds of localization, but in
>> this context, we're mainly concerned with message strings.)
>>
>> In general, we don't localize tests. In the specific cases of the RMI
>> CheckUsage and SetChildEnv tests, modifying them to use different
>> message strings based on the current locale is unacceptable.
>>
>>>> Bottom line is that I do not think it makes sense to localize these
>>>> tests.
>>> Stuart, as I already mention before, what is important is that the jdk
>>> tests
>>> pass OK whatever country there are run. So those specific tests that
>>> fails even
>>> if the localization is preset to Locale.US must be corrected to pass
>>> in non US
>>> country or removed.
>>
>> Our statements aren't actually contradicting each other. I agree that
>> the failing tests need to be corrected or removed. I'm also stating the
>> localizing the tests is not the way to correct them. They must be dealt
>> with some other way.
>>
>> * * *
>>
>> OK, let's step back from this and take inventory. The patch contained
>> fixes for the following tests, presumably because they failed when run
>> in the French locale. For each failing test, what should be done about it?
>>
>> test/java/rmi/activation/CommandEnvironment/SetChildEnv.java
>>   - JDK-8027873: fix RMI test library to run rmid in the US locale
>>
>> test/java/rmi/activation/checkusage/CheckUsage.java
>>   - JDK-8027810: this test should be removed
>>
>> test/java/util/Formattable/StockName.java
>> test/java/util/ResourceBundle/ResourceBundleTest.java
>> test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java
>> test/java/util/logging/LocalizedLevelName.java
>> test/java/util/logging/SimpleFormatterFormat.java
>> test/sun/util/logging/SourceClassName.java
>>
>>   - Internationalization folks, what should be done about these tests?
>>
>>
>> s'marks
>
>