Re: [8]: diff patch for jdk test on a non US platform

Francis ANDRE Wed, 06 Nov 2013 11:56:27 -0800

HI

To add a little bit more of clarity for the i18n problems in the ResourceBundletests, joined is an extract from the log of their failures before I fixed themfor 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 capableof whatever the default locale is, so the test failure needs to beinvestigated 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

Re: [8]: diff patch for jdk test on a non US platform

Reply via email to