db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vemund Østgaard (JIRA) <j...@apache.org>
Subject [jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
Date Fri, 25 Jan 2008 10:54:35 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562434#action_12562434

Vemund Østgaard commented on DERBY-3320:

I am not sure if there is an easier way to check for Locale support, I used your method when
making a patch for the tests to avoid running them when the locale to test with was not available.
It has not been committed yet, though.

I think maybe that Locale.getAvailableLocales() doesn't necessarily have to return the same
list of supported Locales as Collator.getSupportedLocales(), or other locale-dependent classes
with the getSupportedLocales() method. So maybe it is important to check what returned by
the functionality that will be used, like Collator.

Take a look at the javadoc for java.util.spi.LocaleServiceProvider, it seems all the different
locale-dependant provider classes are subclasses of this. The second last paragraph says:

Locale sensitive factory methods and methods for name retrieval in the java.text and java.util
packages invoke service provider methods when needed to support the requested locale. The
methods first check whether the Java runtime environment itself supports the requested locale,
and use its support if available. Otherwise, they call the getAvailableLocales() methods of
installed providers for the appropriate interface to find one that supports the requested
locale. If such a provider is found, its other methods are called to obtain the requested
object or name. If neither the Java runtime environment itself nor an installed provider supports
the requested locale, a fallback locale is constructed by replacing the first of the variant,
country, or language strings of the locale that's not an empty string with an empty string,
and the lookup process is restarted. In the case that the variant contains one or more '_'s,
the fallback locale is constructed by replacing the variant with a new variant which eliminates
the last '_' and the part following it. Even if a fallback occurs, methods that return requested
objects or name are invoked with the original locale before the fallback.The Java runtime
environment must support the root locale for all locale sensitive services in order to guarantee
that this process terminates.

So, I think you will have to go through the list of supported locales for the functionality
that will be used. Maybe that is only Collator?

Something to consider is also whether you need an exact match to consider a locale supported
for the purpose of the Collator, or if it is enough to get a language match? For instance,
if looking for en_GB, is en_US good enough? Maybe if a partial match is found, the DB should
be allowed to boot but write a warning about it only finding a partial match?

> Database creation and boot should fail if collation=TERRITORY_BASED and the selected
locale is not supported
> ------------------------------------------------------------------------------------------------------------
>                 Key: DERBY-3320
>                 URL: https://issues.apache.org/jira/browse/DERBY-3320
>             Project: Derby
>          Issue Type: Bug
>    Affects Versions:
>         Environment: Java ME:
> Product: phoneME Advanced (phoneme_advanced_mr2-b34)
> Profile: Foundation Profile Specification 1.1
> Linux 2.4.21-40.ELsmp #1 SMP Thu Feb 2 22:14:12 EST 2006 i686 athlon i386 GNU/Linux
>            Reporter: Vemund Østgaard
>            Assignee: Mamta A. Satoor
>         Attachments: DERBY_3320_Repro.java
> A problem I've discovered when testing with the phoneME advanced platform is that the
collationtests expect other locales than Locale.US to be available on the platform that is
used for the test, and for phoneME advanced (when compiled as foundation profile) only Locale.US
is available. From the jdk1.6 javadoc of Collator.getAvailableLocales() I see that only Locale.US
is strictly required:
> public static Locale[] getAvailableLocales()
>     Returns an array of all locales for which the getInstance methods of this class can
return localized instances. The returned array represents the union of locales supported by
the Java runtime and by installed CollatorProvider implementations. It must contain at least
a Locale instance equal to Locale.US.
>     Returns:
>         An array of locales for which localized Collator instances are available.
> This led me to thinking about how Derby should behave if created/booted with collation=TERRITORY_BASED
and territory=<some unsupported locale>. I'm not sure what the consequences could be
if the database is first created on a platform that supports whatever locale is set and later
booted with one that doesn't, or created on a platform missing support and later booted with
one that has. In any case I think it may confuse a user needlessly to see the database boot
successfully with his collation setting and later behave in a way he does not expect.
> Opinions voiced on the derby-dev list are that both database creation and boot should
fail if collation=TERRITORY_BASED and the selected locale is not supported.
> If a change like this is implemented, the collationtests should be changed to verify
correct behavior also if they are executed in an environment were some of the tested locales
are not supported.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message