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

Tue Nov 5 15:43:51 PST 2013

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